Apparatus, system, and method for managing commands of solid-state storage using bank interleave

ABSTRACT

An apparatus, system, and method are disclosed for efficiently managing commands in a solid-state storage device that includes a solid-state storage arranged in two or more banks. Each bank is separately accessible and includes two or more solid-state storage elements accessed in parallel by a storage input/output bus. The solid-state storage includes solid-state, non-volatile memory. The solid-state storage device includes a bank interleave that directs one or more commands to two or more queues, where the one or more commands are separated by command type into the queues. Each bank includes a set of queues in the bank interleave controller. Each set of queues includes a queue for each command type. The bank interleave controller coordinates among the banks execution of the commands stored in the queues, where a command of a first type executes on one bank while a command of a second type executes on a second bank.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent ApplicationNo. 60/873,111 entitled “Elemental Blade System” and filed on Dec. 6,2006 for David Flynn, et al., and U.S. Provisional Patent ApplicationNo. 60/974,470 entitled “Apparatus, System, and Method forObject-Oriented Solid-State Storage” and filed on Sep. 22, 2007 forDavid Flynn, et al., which are incorporated herein by reference.

BACKGROUND OF THE INVENTION

Field of the Invention

This invention relates to solid-state storage and more particularlyrelates to efficiently managing command execution in solid-state storageusing a bank interleave controller.

Description of the Related Art

Data storage devices are typically write-in-place in that data accessedat a particular location can be modified and then put back in the samelocation. A file or object may be divided and placed piecemeal in thedata storage device in various locations where no data is stored orwhere data is marked invalid. While this method works well for devicessuch as a hard disk drive (“HDD”), using write-in-place for solid-statestorage can be inefficient and can cause premature failure.

Using write-in-place for solid-state storage can be inefficient becausetypically writing data often takes much longer than reading data. Forflash memory, which is a type of solid-state storage, changing a bitfrom a “zero” state (“zero”) to a “one” state (“one”) usually takeslonger than changing a bit from a one to a zero. This is the case fortypical flash memory that uses capacitors as cells where a zero equatesto a discharged capacitor in a cell and a one equates to a chargedcapacitor in a cell. Typically, charging a capacitor takes longer thandischarging a capacitor.

Using write-in-place for solid-state storage can lead to prematurefailure of the solid-state storage because typically each cell in asolid-state storage device can only be written to a certain number oftimes before the cell begins to fail. Write-in-place typically does notevenly distribute writing data over the solid-state storage so someregions or addresses are used much more than other areas. This overuseof some areas can lead to premature failure of all or a portion of asolid-state storage device.

Traditional write-in-place and other data handling techniques associateddata management techniques associated with write-in-place and othertraditional storage prevent solid-state storage from achieving muchhigher possible performance.

SUMMARY OF THE INVENTION

From the foregoing discussion, it should be apparent that a need existsfor an apparatus, system, and method that efficiently manage commands ofa solid-state storage device. Beneficially, such an apparatus, system,and method would queue commands for each bank of a solid-state storagedevice and coordinate execution of the commands.

The present invention has been developed in response to the presentstate of the art, and in particular, in response to the problems andneeds in the art that have not yet been fully solved by currentlyavailable solid-state storage. Accordingly, the present invention hasbeen developed to provide an apparatus, system, and method forefficiently managing commands for solid-state storage using a bankinterleave that overcome many or all of the above-discussed shortcomingsin the art.

The apparatus includes a solid-state storage device to manage commandsof a solid-state storage device is provided with a plurality of modulesand hardware configured to functionally execute the necessary steps ofdirecting commands to queues for each bank of a solid-state storagedevice and coordinate execution of the commands. The solid-state storagedevice in the described embodiments includes a solid-state storagearranged in two or more banks, each bank being separately accessible andeach bank including two or more solid-state storage elements accessed inparallel by a storage input/output (“I/O”) bus. The solid-state storageincludes solid-state, non-volatile memory. The solid-state storagedevice includes a bank interleave controller. The bank interleavecontroller directs one or more commands to two or more queues. The oneor more commands are separated by command type into the queues. Eachbank includes a set of queues in the bank interleave controller. Eachset of queues includes a queue for each command type. The bankinterleave controller coordinates among the banks execution of thecommands stored in the queues, where a command of a first type executeson one bank while a command of a second type executes on a second bank.

In one embodiment, the set of queues for a bank include a read queue tostore read commands, a write queue to store write commands, an erasequeue to store erase commands, and a management queue to storemanagement commands and wherein the command types comprise at leastread, write, and erase commands. In another embodiment, a read commandreads data from a location within a page in the solid-state storage, awrite command writes data to a storage write buffer, the storage writebuffer located in the solid-state storage and comprising data fortransfer to a designated page in the solid-state storage in response toa program command that programs data in the storage write buffer to thedesignated page, and an erase command to erase data in an erase block,an erase block comprising a plurality of pages in the solid-statestorage.

In one embodiment, the command types also include a reset command toreset a bank and a read configuration register command to read aconfiguration register of a bank. The reset and read configurationregister commands are stored in the management queue of each bank. Inanother embodiment, the bank interleave controller also coordinatesexecution of commands not stored the queues with execution of commandsstored in the queues.

In one embodiment, the solid-state storage device includes a bankcontroller for each bank, where a bank controller for a bank receivesand interprets a command from a queue of the bank and creates one ormore subcommands from the received command. The one or more subcommandsinclude commands directed at the bank. In the embodiment, thesolid-state storage device also includes a bus arbiter that coordinatesexecution of the subcommands. In a further embodiment, the bankinterleave controller uses predicted command execution durationinformation of commands and subcommands and status information receivedfrom the solid-state storage to predict and verify command completion aspart of coordinating execution of the commands stored in the sets ofqueues.

In one embodiment, the bank interleave controller combines one or moredata packets stored in a write buffer with a write command prior tosending the data packets and write command to the solid-state storagevia a storage input/output (“I/O”) bus and receives one or more datapackets and corresponding status and management data and forwards thedata packets read from the solid-state storage to a read buffer and thecorresponding status and management data to a management buffer. In oneembodiment, the bank interleave controller coordinates execution of readcommands, write commands, and erase commands on the two or more banks,where the read commands, write commands, and erase commands are storedin the set of queues for each bank, so that when a read, write, or erasecommand completes on one bank, another read, write, or erase command issent to the bank.

In another embodiment, the storage I/O bus is asynchronous andtransports data packets comprising control information and data. Inanother embodiment, the solid-state storage device includes a controllerwith a write data pipeline and a read data pipeline. The bank interleavecontroller coordinates reading and writing data with the write datapipeline and the read data pipeline. In various embodiments, thesolid-state storage device may be configured in a dual-inline memorymodule (“DIMM”), a daughter card, a micro-module, etc. In otherembodiments, the solid-state storage of the solid-state storage devicemay be flash memory, nano random access memory (“nano RAM” or “NRAM”),magneto-resistive RAM (“MRAM”), dynamic RAM (“DRAM”), phase change RAM(“PRAM”), etc. In yet another embodiment, commands sent to thesolid-state storage are sent asynchronously.

In one embodiment, storage locations within a solid-state storageelement of the two or more solid-state storage elements are accessedwith a logical address mapped to one or more storage location bycorresponding physical addresses of the one or more storage locations.In the embodiment, the solid-state storage device includes a remappingmodule that remaps a first logical address mapped to a first physicaladdress to a second physical address such that data commands sent to astorage location represented by the first logical address are directedto the first physical address prior to remapping and to the secondphysical address after remapping.

In another embodiment, a write buffer accessible to the bank interleavecontroller and a storage write buffer within the solid-state storage,where the write buffer and the storage write buffer have a storagecapacity equal to or greater than a page within the solid-state storage.In the embodiment, data to be written to the solid-state storage isstored in the write buffer and the bank interleave controller transfersdata segments to fill a page of memory to the storage write bufferduring a write operation. The data segments in the storage write bufferare subsequently stored in a page within the solid-state storage inresponse to a program command.

A system of the present invention is also presented to coordinatecommands in a solid-state storage device using a bank interleave. Thesystem may be embodied by a computer, a system bus, a solid-statestorage device in communication with the computer via the system bus toservice at least data read and write requests. In particular, thesolid-state storage device, in one embodiment, includes a solid-statestorage arranged in two or more banks, where each bank is separatelyaccessible and each bank includes two or more solid-state storage diesaccessed in parallel by a storage I/O bus. The solid-state storageincludes solid-state, non-volatile memory. The solid-state storagedevice includes a bank interleave controller. The bank interleavecontroller includes a command segregation module that directs one ormore commands to two or more queues. The one or more commands areseparated by command type into the queues. The bank interleave includesa set of queues for each bank. Each set of queues includes a queue foreach command type. The bank interleave controller coordinates among thebanks execution of the commands stored in the queues, where a command ofa first type executes on one bank while a command of a second typeexecutes on a second bank.

The system may further include a computer network and a client incommunication with the computer through the computer network. The clientsends data and management requests to the solid-state storage devicethrough the computer. The computer forwards the data and managementrequests to the solid-state storage device and returns responses fromthe solid-state storage device to the client. In one embodiment, thesystem bus includes a peripheral component interconnect express(“PCI-e”) bus, a universal serial bus (“USB”) connection, an Instituteof Electrical and Electronics Engineers (“IEEE”) 1394 bus, Infiniband,Ethernet, or a combination of the system bus types.

In one embodiment, the set of queues for a bank include a read queue tostore read commands, a write queue to store write commands, an erasequeue to store erase commands, and a management queue to storemanagement commands and wherein the command types comprise at leastread, write, program, and erase commands. In another embodiment, thesystem includes a controller. The controller includes a write datapipeline and a read data pipeline, where the bank interleave controllerreceives the one or more commands from the controller and coordinatesreading and writing data with the write data pipeline and the read datapipeline.

A method of the present invention is also presented for managingcommands of a solid-state storage device. The method in the disclosedembodiments substantially includes the steps necessary to carry out thefunctions presented above with respect to the operation of the describedapparatus and system. In one embodiment, the method includes directingone or more commands to two or more queues of a solid-state storagedevice, where the one or more commands are separated by command typeinto the queues. The solid-state storage device includes solid-statestorage arranged in two or more banks. Each bank is separatelyaccessible and each bank includes two or more solid-state storageelements accessed in parallel by a storage I/O bus. The solid-statestorage includes solid-state, non-volatile memory. Each bank includes aset of queues and each set of queues includes a queue for each commandtype. The method also includes coordinating among the banks execution ofthe commands stored in the queues, where a command of a first typeexecutes on one bank while a command of a second type executes on asecond bank.

Reference throughout this specification to features, advantages, orsimilar language does not imply that all of the features and advantagesthat may be realized with the present invention should be or are in anysingle embodiment of the invention. Rather, language referring to thefeatures and advantages is understood to mean that a specific feature,advantage, or characteristic described in connection with an embodimentis included in at least one embodiment of the present invention. Thus,discussion of the features and advantages, and similar language,throughout this specification may, but do not necessarily, refer to thesame embodiment.

Furthermore, the described features, advantages, and characteristics ofthe invention may be combined in any suitable manner in one or moreembodiments. One skilled in the relevant art will recognize that theinvention may be practiced without one or more of the specific featuresor advantages of a particular embodiment. In other instances, additionalfeatures and advantages may be recognized in certain embodiments thatmay not be present in all embodiments of the invention.

These features and advantages of the present invention will become morefully apparent from the following description and appended claims, ormay be learned by the practice of the invention as set forthhereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the advantages of the invention will be readilyunderstood, a more particular description of the invention brieflydescribed above will be rendered by reference to specific embodimentsthat are illustrated in the appended drawings. Understanding that thesedrawings depict only typical embodiments of the invention and are nottherefore to be considered to be limiting of its scope, the inventionwill be described and explained with additional specificity and detailthrough the use of the accompanying drawings, in which:

FIG. 1A is a schematic block diagram illustrating one embodiment of asystem for data management in a solid-state storage device in accordancewith the present invention;

FIG. 1B is a schematic block diagram illustrating one embodiment of asystem for object management in a storage device in accordance with thepresent invention;

FIG. 2A is a schematic block diagram illustrating one embodiment of anapparatus for object management in a storage device in accordance withthe present invention;

FIG. 2B is a schematic block diagram illustrating one embodiment of asolid-state storage device controller in a solid-state storage device inaccordance with the present invention;

FIG. 3 is a schematic block diagram illustrating one embodiment of asolid-state storage controller with a write data pipeline and a readdata pipeline in a solid-state storage device in accordance with thepresent invention;

FIG. 4A is a schematic block diagram illustrating one embodiment of abank interleave controller in the solid-state storage controller inaccordance with the present invention;

FIG. 4B is a schematic block diagram illustrating an alternateembodiment of a bank interleave controller in the solid-state storagecontroller in accordance with the present invention;

FIG. 5 is a schematic flow chart diagram illustrating one embodiment ofa method for managing data in a solid-state storage device using a datapipeline in accordance with the present invention;

FIG. 6 is a schematic flow chart diagram illustrating another embodimentof a method for managing data in a solid-state storage device using adata pipeline in accordance with the present invention; and

FIG. 7 is a schematic flow chart diagram illustrating an embodiment of amethod for managing data in a solid-state storage device using a bankinterleave in accordance with the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Many of the functional units described in this specification have beenlabeled as modules, in order to more particularly emphasize theirimplementation independence. For example, a module may be implemented asa hardware circuit comprising custom VLSI circuits or gate arrays,off-the-shelf semiconductors such as logic chips, transistors, or otherdiscrete components. A module may also be implemented in programmablehardware devices such as field programmable gate arrays, programmablearray logic, programmable logic devices or the like.

Modules may also be implemented in software for execution by varioustypes of processors. An identified module of executable code may, forinstance, comprise one or more physical or logical blocks of computerinstructions which may, for instance, be organized as an object,procedure, or function. Nevertheless, the executables of an identifiedmodule need not be physically located together, but may comprisedisparate instructions stored in different locations which, when joinedlogically together, comprise the module and achieve the stated purposefor the module.

Indeed, a module of executable code may be a single instruction, or manyinstructions, and may even be distributed over several different codesegments, among different programs, and across several memory devices.Similarly, operational data may be identified and illustrated hereinwithin modules, and may be embodied in any suitable form and organizedwithin any suitable type of data structure. The operational data may becollected as a single data set, or may be distributed over differentlocations including over different storage devices, and may exist, atleast partially, merely as electronic signals on a system or network.Where a module or portions of a module are implemented in software, thesoftware portions are stored on one or more computer readable media.

Reference throughout this specification to “one embodiment,” “anembodiment,” or similar language means that a particular feature,structure, or characteristic described in connection with the embodimentis included in at least one embodiment of the present invention. Thus,appearances of the phrases “in one embodiment,” “in an embodiment,” andsimilar language throughout this specification may, but do notnecessarily, all refer to the same embodiment.

Reference to a signal bearing medium may take any form capable ofgenerating a signal, causing a signal to be generated, or causingexecution of a program of machine-readable instructions on a digitalprocessing apparatus. A signal bearing medium may be embodied by atransmission line, a compact disk, digital-video disk, a magnetic tape,a Bernoulli drive, a magnetic disk, a punch card, flash memory,integrated circuits, or other digital processing apparatus memorydevice.

Furthermore, the described features, structures, or characteristics ofthe invention may be combined in any suitable manner in one or moreembodiments. In the following description, numerous specific details areprovided, such as examples of programming, software modules, userselections, network transactions, database queries, database structures,hardware modules, hardware circuits, hardware chips, etc., to provide athorough understanding of embodiments of the invention. One skilled inthe relevant art will recognize, however, that the invention may bepracticed without one or more of the specific details, or with othermethods, components, materials, and so forth. In other instances,well-known structures, materials, or operations are not shown ordescribed in detail to avoid obscuring aspects of the invention.

The schematic flow chart diagrams included herein are generally setforth as logical flow chart diagrams. As such, the depicted order andlabeled steps are indicative of one embodiment of the presented method.Other steps and methods may be conceived that are equivalent infunction, logic, or effect to one or more steps, or portions thereof, ofthe illustrated method. Additionally, the format and symbols employedare provided to explain the logical steps of the method and areunderstood not to limit the scope of the method. Although various arrowtypes and line types may be employed in the flow chart diagrams, theyare understood not to limit the scope of the corresponding method.Indeed, some arrows or other connectors may be used to indicate only thelogical flow of the method. For instance, an arrow may indicate awaiting or monitoring period of unspecified duration between enumeratedsteps of the depicted method. Additionally, the order in which aparticular method occurs may or may not strictly adhere to the order ofthe corresponding steps shown.

Solid-State Storage System

FIG. 1A is a schematic block diagram illustrating one embodiment of asystem 100 for data management in a solid-state storage device inaccordance with the present invention. The system 100 includes asolid-state storage device 102, a solid-state storage controller 104, awrite data pipeline 106, a read data pipeline 108, a solid-state storage110, a computer 112, a client 114, and a computer network 116, which aredescribed below.

The system 100 includes at least one solid-state storage device 102. Inanother embodiment, the system 100 includes two or more solid-statestorage devices 102. Each solid-state storage device 102 may includenon-volatile, solid-state storage 110, such as flash memory, nano randomaccess memory (“nano RAM or NRAM”), magneto-resistive RAM (“MRAM”),dynamic RAM (“DRAM”), phase change RAM (“PRAM”), etc. The solid-statestorage device 102 is described in more detail with respect to FIGS. 2and 3. The solid-state storage device 102 is depicted in a computer 112connected to a client 114 through a computer network 116. In oneembodiment, the solid-state storage device 102 is internal to thecomputer 112 and is connected using a system bus, such as a peripheralcomponent interconnect express (“PCI-e”) bus, a Serial AdvancedTechnology Attachment (“serial ATA”) bus, or the like. In anotherembodiment, the solid-state storage device 102 is external to thecomputer 112 and is connected, a universal serial bus (“USB”)connection, an Institute of Electrical and Electronics Engineers(“IEEE”) 1394 bus (“FireWire”), or the like. In other embodiments, thesolid-state storage device 102 is connected to the computer 112 using aperipheral component interconnect (“PCI”) express bus using externalelectrical or optical bus extension or bus networking solution such asInfiniband or PCI Express Advanced Switching (“PCIe-AS”), or the like.

In various embodiments, the solid-state storage device 102 may be in theform of a dual-inline memory module (“DIMM”), a daughter card, or amicro-module. In another embodiment, the solid-state storage device 102is an element within a rack-mounted blade. In another embodiment, thesolid state storage device 102 is contained within a package that isintegrated directly onto a higher level assembly (e.g. mother board, laptop, graphics processor). In another embodiment, individual componentscomprising the solid-state storage device 102 are integrated directlyonto a higher level assembly without intermediate packaging.

The solid-state storage device 102 includes one or more solid-statestorage controllers 104, each may include a write data pipeline 106 anda read data pipeline 108 and each includes a solid-state storage 110,which are described in more detail below with respect to FIGS. 2 and 3.

The system 100 includes one or more computers 112 connected to thesolid-state storage device 102. A computer 112 may be a host, a server,a storage controller of a storage area network (“SAN”), a workstation, apersonal computer, a laptop computer, a handheld computer, asupercomputer, a computer cluster, a network switch, router, orappliance, a database or storage appliance, a data acquisition or datacapture system, a diagnostic system, a test system, a robot, a portableelectronic device, a wireless device, or the like. In anotherembodiment, a computer 112 may be a client and the solid-state storagedevice 102 operates autonomously to service data requests sent from thecomputer 112. In this embodiment, the computer 112 and solid-statestorage device 102 may be connected using a computer network, systembus, or other communication means suitable for connection between acomputer 112 and an autonomous solid-state storage device 102.

In one embodiment, the system 100 includes one or more clients 114connected to one or more computers 112 through one or more computernetworks 116. A client 114 may be a host, a server, a storage controllerof a SAN, a workstation, a personal computer, a laptop computer, ahandheld computer, a supercomputer, a computer cluster, a networkswitch, router, or appliance, a database or storage appliance, a dataacquisition or data capture system, a diagnostic system, a test system,a robot, a portable electronic device, a wireless device, or the like.The computer network 116 may include the Internet, a wide area network(“WAN”), a metropolitan area network (“MAN”), a local area network(“LAN”), a token ring, a wireless network, a fiber channel network, aSAN, network attached storage (“NAS”), ESCON, or the like, or anycombination of networks. The computer network 116 may also include anetwork from the IEEE 802 family of network technologies, such Ethernet,token ring, WiFi, WiMax, and the like.

The computer network 116 may include servers, switches, routers,cabling, radios, and other equipment used to facilitate networkingcomputers 112 and clients 114. In one embodiment, the system 100includes multiple computers 112 that communicate as peers over acomputer network 116. In another embodiment, the system 100 includesmultiple solid-state storage devices 102 that communicate as peers overa computer network 116. One of skill in the art will recognize othercomputer networks 116 comprising one or more computer networks 116 andrelated equipment with single or redundant connection between one ormore clients 114 or other computer with one or more solid-state storagedevices 102 or one or more solid-state storage devices 102 connected toone or more computers 112. In one embodiment, the system 100 includestwo or more solid-state storage devices 102 connected through thecomputer network 116 to a client 114 without a computer 112.

Storage Controller-Managed Objects

FIG. 1B is a schematic block diagram illustrating one embodiment of asystem 101 for object management in a storage device in accordance withthe present invention. The system 101 includes one or more storagedevices 150, each with a storage controller 152 and one or more datastorage devices 154, and one or more requesting devices 155. The storagedevices 150 are networked together and coupled to one or more requestingdevices 155. The requesting device 155 sends object requests to astorage device 150 a. An object request may be a request to create anobject, a request to write data to an object, a request to read datafrom an object, a request to delete an object, a request to checkpointan object, a request to copy an object, and the like. One of skill inthe art will recognize other object requests.

In one embodiment, the storage controller 152 and data storage device154 are separate devices. In another embodiment, the storage controller152 and data storage device 154 are integrated into one storage device150. In another embodiment, a data storage device 154 is a solid-statestorage 110 and the storage controller 152 is a solid-state storagedevice controller 202. In other embodiments, a data storage device 154may be a hard disk drive, an optical drive, tape storage, or the like.In another embodiment, a storage device 150 may include two or more datastorage devices 154 of different types.

In one embodiment, the data storage device 154 is a solid-state storage110 and is arranged as an array of solid-state storage elements 216,218, 220. In another embodiment, the solid-state storage 110 is arrangedin two or more banks 214 a-n. Solid-state storage 110 is described inmore detail below with respect to FIG. 2B.

The storage devices 150 a-n may be networked together and act as adistributed storage device. The storage device 150 a coupled to therequesting device 155 controls object requests to the distributedstorage device. In one embodiment, the storage devices 150 andassociated storage controllers 152 manage objects and appear to therequesting device(s) 155 as a distributed object file system. In thiscontext, a parallel object file system is an example of a type ofdistributed object file system. In another embodiment, the storagedevices 150 and associated storage controllers 152 manage objects andappear to the requesting device(s) 155 as distributed object fileservers. In this context, a parallel object file server is an example ofa type of distributed object file server. In these and other embodimentsthe requesting device 155 may exclusively manage objects or participatein managing objects in conjunction with storage devices 150; thistypically does not limit the ability of storage devices 150 to fullymanage objects for other clients 114. In the degenerate case, eachdistributed storage device, distributed object file system anddistributed object file server can operate independently as a singledevice. The networked storage devices 150 a-n may operate as distributedstorage devices, distributed object file systems, distributed objectfile servers, and any combination thereof having images of one or moreof these capabilities configured for one or more requesting devices 155.For example, the storage devices 150 may be configured to operate asdistributed storage devices for a first requesting device 155 a, whileoperating as distributed storage devices and distributed object filesystems for requesting devices 155 b. Where the system 101 includes onestorage device 150 a, the storage controller 152 a of the storage device150 a manages objects may appear to the requesting device(s) 155 as anobject file system or an object file server.

In one embodiment where the storage devices 150 are networked togetheras a distributed storage device, the storage devices 150 serve as aredundant array of independent drives (“RAID”) managed by one or moredistributed storage controllers 152. For example, a request to write adata segment of an object results in the data segment being stripedacross the data storage devices 154 a-n with a parity stripe, dependingupon the RAID level. One benefit of such an arrangement is that such anobject management system may continue to be available when a singlestorage device 150 has a failure, whether of the storage controller 152,the data storage device 154, or other components of storage device 150.

When redundant networks are used to interconnect the storage devices 150and requesting devices 155, the object management system may continue tobe available in the presence of network failures as long as one of thenetworks remains operational. A system 101 with a single storage device150 a may also include multiple data storage devices 154 a and thestorage controller 152 a of the storage device 150 a may act as a RAIDcontroller and stripe the data segment across the data storage devices154 a of the storage device 150 a and may include a parity stripe,depending upon the RAID level.

In one embodiment, where the one or more storage devices 150 a-n aresolid-state storage devices 102 with a solid-state storage devicecontroller 202 and solid-state storage 110, the solid-state storagedevice(s) 102 may be configured in a DIMM configuration, daughter card,micro-module, etc. and reside in a computer 112. The computer 112 may bea server or similar device with the solid-state storage devices 102networked together and acting as distributed RAID controllers.Beneficially, the storage devices 102 may be connected using PCI-e,PCIe-AS, Infiniband or other high-performance bus, switched bus,networked bus, or network and may provide a very compact, highperformance RAID storage system with single or distributed solid-statestorage controllers 202 autonomously striping a data segment acrosssolid-state storage 110 a-n.

In one embodiment, the same network used by the requesting device 155 tocommunicate with storage devices 150 may be used by the peer storagedevice 150 a to communicate with peer storage devices 150 b-n toaccomplish RAID functionality. In another embodiment, a separate networkmay be used between the storage devices 150 for the purpose of RAIDing.In another embodiment, the requesting devices 155 may participate in theRAIDing process by sending redundant requests to the storage devices150. For example, requesting device 155 may send a first object writerequest to a first storage device 150 a and a second object writerequest with the same data segment to a second storage device 150 b toachieve simple mirroring.

With the ability for object handling within the storage device(s) 102,the storage controller(s) 152 uniquely have the ability to store onedata segment or object using one RAID level while another data segmentor object is stored using a different RAID level or without RAIDstriping. These multiple RAID groupings may be associated with multiplepartitions within the storage devices 150. RAID 0, RAID 1, RAID5, RAID6and composite RAID types 10, 50, 60, can be supported simultaneouslyacross a variety of RAID groups comprising data storage devices 154 a-n.One skilled in the art will recognize other RAID types andconfigurations that may also be simultaneously supported.

Also, because the storage controller(s) 152 operate autonomously as RAIDcontrollers, the RAID controllers can perform progressive RAIDing andcan transform objects or portions of objects striped across data storagedevices 154 with one RAID level to another RAID level without therequesting device 155 being affected, participating or even detectingthe change in RAID levels. In the preferred embodiment, progressing theRAID configuration from one level to another level may be accomplishedautonomously on an object or even a packet basis and is initiated by adistributed RAID control module operating in one of the storage devices150 or the storage controllers 152. Typically, RAID progression will befrom a higher performance and lower efficiency storage configurationsuch as RAID1 to a lower performance and higher storage efficiencyconfiguration such as RAID5 where the transformation is dynamicallyinitiated based on the frequency of access. But, one can see thatprogressing the configuration from RAID5 to RAID1 is also possible.Other processes for initiating RAID progression may be configured orrequested from clients or external agents such a storage systemmanagement server request. One of skill in the art will recognize otherfeatures and benefits of a storage device 102 with a storage controller152 that autonomously manages objects.

Apparatus for Storage Controller-Managed Objects

FIG. 2A is a schematic block diagram illustrating one embodiment of anapparatus 200 for object management in a storage device in accordancewith the present invention. The apparatus 200 includes a storagecontroller 152 with an object request receiver module 260, a parsingmodule 262, a command execution module 264, an object index module 266,an object request queuing module 268, a packetizer 302 with a messagesmodule 270, and an object index reconstruction module 272, which aredescribed below.

The storage controller 152 is substantially similar to the storagecontroller 152 described in relation to the system 101 of FIG. 1B andmay be a solid-state storage device controller 202 described in relationto FIG. 2. The apparatus 200 includes an object request receiver module260 that receives an object request from one or more requesting devices155. For example, for a store object data request, the storagecontroller 152 stores the data segment as a data packet in a datastorage device 154 coupled to the storage controller 152. The objectrequest is typically directed at a data segment stored or to be storedin one or more object data packets for an object managed by the storagecontroller 152. The object request may request that the storagecontroller 152 create an object to be later filled with data throughlater object request which may utilize a local or remote direct memoryaccess (“DMA,” “RDMA”) transfer.

In one embodiment, the object request is a write request to write all orpart of an object to a previously created object. In one example, thewrite request is for a data segment of an object. The other datasegments of the object may be written to the storage device 150 or toother storage devices. In another example, the write request is for anentire object. In another example, the object request is to read datafrom a data segment managed by the storage controller 152. In yetanother embodiment, the object request is a delete request to delete adata segment or object.

Advantageously, the storage controller 152 can accept write requeststhat do more than write a new object or append data to an existingobject. For example, a write request received by the object requestreceiver module 260 may include a request to add data ahead of datastored by the storage controller 152, to insert data into the storeddata, or to replace a segment of data. The object index maintained bythe storage controller 152 provides the flexibility required for thesecomplex write operations that is not available in other storagecontrollers, but is currently available only outside of storagecontrollers in file systems of servers and other computers.

The apparatus 200 includes a parsing module 262 that parses the objectrequest into one or more commands. Typically, the parsing module 262parses the object request into one or more buffers. For example, one ormore commands in the object request may be parsed into a command buffer.Typically the parsing module 262 prepares an object request so that theinformation in the object request can be understood and executed by thestorage controller 152. One of skill in the art will recognize otherfunctions of a parsing module 262 that parses an object request into oneor more commands.

The apparatus 200 includes a command execution module 264 that executesthe command(s) parsed from the object request. In one embodiment, thecommand execution module 264 executes one command. In anotherembodiment, the command execution module 264 executes multiple commands.Typically, the command execution module 264 interprets a command parsedfrom the object request, such as a write command, and then creates,queues, and executes subcommands. For example, a write command parsedfrom an object request may direct the storage controller 152 to storemultiple data segments. The object request may also include requiredattributes such as encryption, compression, etc. The command executionmodule 264 may direct the storage controller 152 to compress the datasegments, encrypt the data segments, create one or more data packets andassociated headers for each data packet, encrypt the data packets with amedia encryption key, add error correcting code, and store the datapackets a specific location. Storing the data packets at a specificlocation and other subcommands may also be broken down into other lowerlevel subcommands. One of skill in the art will recognize other waysthat the command execution module 264 can execute one or more commandsparsed from an object request.

The apparatus 200 includes an object index module 266 that creates anobject entry in an object index in response to the storage controller152 creating an object or storing the data segment of the object.Typically, the storage controller 152 creates a data packet from thedata segment and the location of where the data packet is stored isassigned at the time the data segment is stored. Object metadatareceived with a data segment or as part of an object request may bestored in a similar way.

The object index module 266 creates an object entry into an object indexat the time the data packet is stored and the physical address of thedata packet is assigned. The object entry includes a mapping between alogical identifier of the object and one or more physical addressescorresponding to where the storage controller 152 stored one or moredata packets and any object metadata packets. In another embodiment, theentry in the object index is created before the data packets of theobject are stored. For example, if the storage controller 152 determinesa physical address of where the data packets are to be stored earlier,the object index module 266 may create the entry in the object indexearlier.

Typically, when an object request or group of object requests results inan object or data segment being modified, possibly during aread-modify-write operation, the object index module 266 updates anentry in the object index corresponding to the modified object. In oneembodiment, the object index creates a new object and a new entry in theobject index module 266 for the modified object. Typically, where only aportion of an object is modified, the object includes modified datapackets and some data packets that remain unchanged. In this case, thenew entry includes a mapping to the unchanged data packets as where theywere originally written and to the modified objects written to a newlocation.

In another embodiment, where the object request receiver module 260receives an object request that includes a command that erases a datablock or other object elements, the storage controller 152 may store atleast one packet such as an erase packet that includes informationincluding a reference to the object, relationship to the object, and thesize of the data block erased. Additionally, it may further indicatethat the erased object elements are filled with zeros. Thus, the eraseobject request can be used to emulate actual memory or storage that iserased and actually has a portion of the appropriate memory/storageactually stored with zeros in the cells of the memory/storage.

Beneficially, creating an object index with entries indicating mappingbetween data segments and metadata of an object allows the storagecontroller 152 to autonomously handle and manage objects. Thiscapability allows a great amount of flexibility for storing data in thestorage device 150. Once the index entry for the object is created,subsequent object requests regarding the object can be servicedefficiently by the storage controller 152.

In one embodiment, the storage controller 152 includes an object requestqueuing module 268 that queues one or more object requests received bythe object request receiver module 260 prior to parsing by the parsingmodule 262. The object request queuing module 268 allows flexibilitybetween when an object request is received and when it is queued.

In another embodiment, the storage controller 152 includes a packetizer302 that creates one or more data packets from the one or more datasegments where the data packets are sized for storage in the datastorage device 154. The packetizer 302 is described below in more detailwith respect to FIG. 3. The packetizer 302 includes, in one embodiment,a messages module 270 that creates a header for each packet. The headerincludes a packet identifier and a packet length. The packet identifierrelates the packet to the object for which the packet was formed.

In one embodiment, each packet includes a packet identifier that isself-contained in that the packet identifier contains adequateinformation to identify the object and relationship within the object ofthe object elements contained within the packet. However, a moreefficient preferred embodiment is to store packets in containers.

A container is a data construct that facilitates more efficient storageof packets and helps establish relationships between an object and datapackets, metadata packets, and other packets related to the object thatare stored within the container. Note that the storage controller 152typically treats object metadata received as part of an object and datasegments in a similar manner. Typically “packet” may refer to a datapacket comprising data, a metadata packet comprising metadata, oranother packet of another packet type. An object may be stored in one ormore containers and a container typically includes packets for no morethan one unique object. An object may be distributed between multiplecontainers. Typically a container is stored within a single logicalerase block (storage division) and is typically never split betweenlogical erase blocks.

A container, in one example, may be split between two or morelogical/virtual pages. A container is identified by a container labelthat associates that container with an object. A container may containzero to many packets and the packets within a container are typicallyfrom one object. A packet may be of many object element types, includingobject attribute elements, object data elements, object index elements,and the like. Hybrid packets may be created that include more than oneobject element type. Each packet may contain zero to many elements ofthe same element type. Each packet within a container typically containsa unique identifier that identifies the relationship to the object.

Each packet is associated with one container. In a preferred embodiment,containers are limited to an erase block so that at or near thebeginning of each erase block a container packet can be found. Thishelps limit data loss to an erase block with a corrupted packet header.In this embodiment, if the object index is unavailable and a packetheader within the erase block is corrupted, the contents from thecorrupted packet header to the end of the erase block may be lostbecause there is possibly no reliable mechanism to determine thelocation of subsequent packets. In another embodiment, a more reliableapproach is to have a container limited to a page boundary. Thisembodiment requires more header overhead. In another embodiment,containers can flow across page and erase block boundaries. Thisrequires less header overhead but a larger portion of data may be lostif a packet header is corrupted. For these several embodiments it isexpected that some type of RAID is used to further ensure dataintegrity.

In one embodiment, the apparatus 200 includes an object indexreconstruction module 272 that that reconstructs the entries in theobject index using information from packet headers stored in the datastorage device 154. In one embodiment, the object index reconstructionmodule 272 reconstructs the entries of the object index by readingheaders to determine the object to which each packet belongs andsequence information to determine where in the object the data ormetadata belongs. The object index reconstruction module 272 usesphysical address information for each packet and timestamp or sequenceinformation to create a mapping between the physical locations of thepackets and the object identifier and data segment sequence. Timestampor sequence information is used by the object index reconstructionmodule 272 to replay the sequence of changes made to the index andthereby typically reestablish the most recent state.

In another embodiment, the object index reconstruction module 272locates packets using packet header information along with containerpacket information to identify physical locations of the packets, objectidentifier, and sequence number of each packet to reconstruct entries inthe object index. In one embodiment, erase blocks are time stamped orgiven a sequence number as packets are written and the timestamp orsequence information of an erase block is used along with informationgathered from container headers and packet headers to reconstruct theobject index. In another embodiment, timestamp or sequence informationis written to an erase block when the erase block is recovered.

Where the object index is stored in volatile memory, an error, loss ofpower, or other problem causing the storage controller 152 to shut downwithout saving the object index could be a problem if the object indexcannot be reconstructed. The object index reconstruction module 272allows the object index to be stored in volatile memory allowing theadvantages of volatile memory, such as fast access. The object indexreconstruction module 272 allows quick reconstruction of the objectindex autonomously without dependence on a device external to thestorage device 150.

In one embodiment, the object index in volatile memory is storedperiodically in a data storage device 154. In a particular example, theobject index, or “index metadata,” is stored periodically in asolid-state storage 110. In another embodiment, the index metadata isstored in a solid-state storage 110 n separate from solid-state storage110 a-110 n−1 storing packets. The index metadata is managedindependently from data and object metadata transmitted from arequesting device 155 and managed by the storage controller152/solid-state storage device controller 202. Managing and storingindex metadata separate from other data and metadata from an objectallows efficient data flow without the storage controller152/solid-state storage device controller 202 unnecessarily processingobject metadata.

In one embodiment, where an object request received by the objectrequest receiver module 260 includes a write request, the storagecontroller 152 receives one or more data segments of an object frommemory of a requesting device 155 as a local or remote direct memoryaccess (“DMA,” “RDMA”) operation. In a preferred example, the storagecontroller 152 pulls data from the memory of the requesting device 155in one or more DMA or RDMA operations. In another example, therequesting device 155 pushes the data segment(s) to the storagecontroller 152 in one or more DMA or RDMA operations. In anotherembodiment, where the object request includes a read request, thestorage controller 152 transmits one or more data segments of an objectto the memory of the requesting device 155 in one or more DMA or RDMAoperations. In a preferred example, the storage controller 152 pushesdata to the memory of the requesting device 155 in one or more DMA orRDMA operations. In another example, the requesting device 155 pullsdata from the storage controller 152 in one or more DMA or RDMAoperations. In another example, the storage controller 152 pulls objectcommand request sets from the memory of the requesting device 155 in oneor more DMA or RDMA operations. In another example, the requestingdevice 155 pushes object command request sets to the storage controller152 in one or more DMA or RDMA operations.

In one embodiment, the storage controller 152 emulates block storage andan object communicated between the requesting device 155 and the storagecontroller 152 comprises one or more data blocks. In one embodiment, therequesting device 155 includes a driver so that the storage device 150appears as a block storage device. For example, the requesting device155 may send a block of data of a certain size along with a physicaladdress of where the requesting device 155 wants the data block stored.The storage controller 152 receives the data block and uses the physicalblock address transmitted with the data block or a transformation of thephysical block address as an object identifier. The storage controller152 then stores the data block as an object or data segment of an objectby packetizing the data block and storing the data block at will. Theobject index module 266 then creates an entry in the object index usingthe physical block-based object identifier and the actual physicallocation where the storage controller 152 stored the data packetscomprising the data from the data block.

In another embodiment, the storage controller 152 emulates block storageby accepting block objects. A block object may include one or more datablocks in a block structure. In one embodiment, the storage controller152 treats the block object as any other object. In another embodiment,an object may represent an entire block device, partition of a blockdevice, or some other logical or physical sub-element of a block deviceincluding a track, sector, channel, and the like. Of particular note isthe ability to remap a block device RAID group to an object supporting adifferent RAID construction such as progressive RAID. One skilled in theart will recognize other mappings of traditional or future block devicesto objects.

Solid-State Storage Device

FIG. 2B is a schematic block diagram illustrating one embodiment 201 ofa solid-state storage device controller 202 that includes a write datapipeline 106 and a read data pipeline 108 in a solid-state storagedevice 102 in accordance with the present invention. The solid-statestorage device controller 202 may include a number of solid-statestorage controllers 0-N 104 a-n, each controlling solid-state storage110. In the depicted embodiment, two solid-state controllers are shown:solid-state controller 0 104 a and solid-state storage controller N 104n, and each controls solid-state storage 110 a-n. In the depictedembodiment, solid-state storage controller 0 104 a controls a datachannel so that the attached solid-state storage 110 a stores data.Solid-state storage controller N 104 n controls an index metadatachannel associated with the stored data and the associated solid-statestorage 110 n stores index metadata. In an alternate embodiment, thesolid-state storage device controller 202 includes a single solid-statecontroller 104 a with a single solid-state storage 110 a. In anotherembodiment, there are a plurality of solid-state storage controllers 104a-n and associated solid-state storage 110 a-n. In one embodiment, oneor more solid state controllers 104 a-104 n−1, coupled to theirassociated solid-state storage 110 a-110 n−1, control data while atleast one solid-state storage controller 104 n, coupled to itsassociated solid-state storage 110 n, controls index metadata.

In one embodiment, at least one solid-state controller 104 isfield-programmable gate array (“FPGA”) and controller functions areprogrammed into the FPGA. In a particular embodiment, the FPGA is aXilinx® FPGA. In another embodiment, the solid-state storage controller104 comprises components specifically designed as a solid-state storagecontroller 104, such as an application-specific integrated circuit(“ASIC”) or custom logic solution. Each solid-state storage controller104 typically includes a write data pipeline 106 and a read datapipeline 108, which are describe further in relation to FIG. 3. Inanother embodiment, at least one solid-state storage controller 104 ismade up of a combination FPGA, ASIC, and custom logic components.

Solid-State Storage

The solid state storage 110 is an array of non-volatile solid-statestorage elements 216, 218, 220, arranged in banks 214, and accessed inparallel through a bi-directional storage input/output (“I/O”) bus 210.The storage I/O bus 210, in one embodiment, is capable of unidirectionalcommunication at any one time. For example, when data is being writtento the solid-state storage 110, data cannot be read from the solid-statestorage 110. In another embodiment, data can flow both directionssimultaneously. However bi-directional, as used herein with respect to adata bus, refers to a data pathway that can have data flowing in onlyone direction at a time, but when data flowing one direction on thebi-directional data bus is stopped, data can flow in the oppositedirection on the bi-directional data bus.

A solid-state storage element (e.g. SSS 0.0 216 a) is typicallyconfigured as a chip (a package of one or more dies) or a die on acircuit board. As depicted, a solid-state storage element (e.g. 216 a)operates independently or semi-independently of other solid-statestorage elements (e.g. 218 a) even if these several elements arepackaged together in a chip package, a stack of chip packages, or someother package element. As depicted, a column of solid-state storageelements 216, 218, 220 is designated as a bank 214. As depicted, theremay be “n” banks 214 a-n and “m” solid-state storage elements 216 a-m,218 a-m, 220 a-m per bank in an array of n×m solid-state storageelements 216, 218, 220 in a solid-state storage 110. In one embodiment,a solid-state storage 110 a includes twenty solid-state storage elements216, 218, 220 per bank 214 with eight banks 214 and a solid-statestorage 110 n includes 2 solid-state storage elements 216, 218 per bank214 with one bank 214. In one embodiment, each solid-state storageelement 216, 218, 220 is comprised of a single-level cell (“SLC”)devices. In another embodiment, each solid-state storage element 216,218, 220 is comprised of multi-level cell (“MLC”) devices.

In one embodiment, solid-state storage elements for multiple banks thatshare a common storage I/O bus 210 a row (e.g. 216 b, 218 b, 220 b) arepackaged together. In one embodiment, a solid-state storage element 216,218, 220 may have one or more dies per chip with one or more chipsstacked vertically and each die may be accessed independently. Inanother embodiment, a solid-state storage element (e.g. SSS 0.0 216 a)may have one or more virtual dies per die and one or more dies per chipand one or more chips stacked vertically and each virtual die may beaccessed independently. In another embodiment, a solid-state storageelement SSS 0.0 216 a may have one or more virtual dies per die and oneor more dies per chip with some or all of the one or more dies stackedvertically and each virtual die may be accessed independently.

In one embodiment, two dies are stacked vertically with four stacks pergroup to form eight storage elements (e.g. SSS 0.0-SSS 0.8) 216 a-220 a,each in a separate bank 214 a-n. In another embodiment, 20 storageelements (e.g. SSS 0.0-SSS 20.0) 216 form a virtual bank 214 a so thateach of the eight virtual banks has 20 storage elements (e.g. SSS0.0-SSS 20.8) 216, 218, 220. Data is sent to the solid-state storage 110over the storage I/O bus 210 to all storage elements of a particulargroup of storage elements (SSS 0.0-SSS 0.8) 216 a, 218 a, 220 a. Thestorage control bus 212 a is used to select a particular bank (e.g.Bank-0 214 a) so that the data received over the storage I/O bus 210connected to all banks 214 is written just to the selected bank 214 a.

In a preferred embodiment, the storage I/O bus 210 is comprised of oneor more independent I/O buses (“IIOBa-m” comprising 210 a.a-m, 210n.a-m) wherein the solid-state storage elements within each row shareone of the independent I/O buses accesses each solid-state storageelement 216, 218, 220 in parallel so that all banks 214 are accessedsimultaneously. For example, one channel of the storage I/O bus 210 mayaccess a first solid-state storage element 216 a, 218 a, 220 a of eachbank 214 a-n simultaneously. A second channel of the storage I/O bus 210may access a second solid-state storage element 216 b, 218 b, 220 b ofeach bank 214 a-n simultaneously. Each row of solid-state storageelement 216, 218, 220 is accessed simultaneously. In one embodiment,where solid-state storage elements 216, 218, 220 are multi-level(physically stacked), all physical levels of the solid-state storageelements 216, 218, 220 are accessed simultaneously. As used herein,“simultaneously” also includes near simultaneous access where devicesare accessed at slightly different intervals to avoid switching noise.Simultaneously is used in this context to be distinguished from asequential or serial access wherein commands and/or data are sentindividually one after the other.

Typically, banks 214 a-n are independently selected using the storagecontrol bus 212. In one embodiment, a bank 214 is selected using a chipenable or chip select. Where both chip select and chip enable areavailable, the storage control bus 212 may select one level of amulti-level solid-state storage element 216, 218, 220. In otherembodiments, other commands are used by the storage control bus 212 toindividually select one level of a multi-level solid-state storageelement 216, 218, 220. Solid-state storage elements 216, 218, 220 mayalso be selected through a combination of control and of addressinformation transmitted on storage I/O bus 210 and the storage controlbus 212.

In one embodiment, each solid-state storage element 216, 218, 220 ispartitioned into erase blocks and each erase block is partitioned intopages. A typical page is 2000 bytes (“2 kB”). In one example, asolid-state storage element (e.g. SSS 0.0) includes two registers andcan program two pages so that a two-register solid-state storage element216, 218, 220 has a capacity of 4 kB. A bank 214 of 20 solid-statestorage elements 216, 218, 220 would then have an 80 kB capacity ofpages accessed with the same address going out the channels of thestorage I/O bus 210.

This group of pages in a bank 214 of solid-state storage elements 216,218, 220 of 80 kB may be called a virtual page. Similarly, an eraseblock of each storage element 216 a-m of a bank 214 a may be grouped toform a virtual erase block. In a preferred embodiment, an erase block ofpages within a solid-state storage element 216, 218, 220 is erased whenan erase command is received within a solid-state storage element 216,218, 220. Whereas the size and number of erase blocks, pages, planes, orother logical and physical divisions within a solid-state storageelement 216, 218, 220 are expected to change over time with advancementsin technology, it is to be expected that many embodiments consistentwith new configurations are possible and are consistent with the generaldescription herein.

Typically, when a packet is written to a particular location within asolid-state storage element 216, 218, 220, wherein the packet isintended to be written to a location within a particular page which isspecific to a particular erase block of a particular element of aparticular bank, a physical address is sent on the storage I/O bus 210and followed by the packet. The physical address contains enoughinformation for the solid-state storage element 216, 218, 220 to directthe packet to the designated location within the page. Since all storageelements in a row of storage elements (e.g. SSS 0.0-SSS 0.N 216 a, 218a, 220 a) are accessed simultaneously by the appropriate bus within thestorage I/O bus 210 a.a, to reach the proper page and to avoid writingthe data packet to similarly addressed pages in the row of storageelements (SSS 0.0-SSS 0.N 216 a, 218 a, 220 a), the bank 214 a thatincludes the solid-state storage element SSS 0.0 216 a with the correctpage where the data packet is to be written is simultaneously selectedby the storage control bus 212.

Similarly, a read command traveling on the storage I/O bus 210 requiresa simultaneous command on the storage control bus 212 to select a singlebank 214 a and the appropriate page within that bank 214 a. In apreferred embodiment, a read command reads an entire page, and becausethere are multiple solid-state storage elements 216, 218, 220 inparallel in a bank 214, an entire virtual page is read with a readcommand. However, the read command may be broken into subcommands, aswill be explained below with respect to bank interleave. A virtual pagemay also be accessed in a write operation.

An erase block erase command may be sent out to erase an erase blockover the storage I/O bus 210 with a particular erase block address toerase a particular erase block. Typically, an erase block erase commandmay be sent over the parallel paths of the storage I/O bus 210 to erasea virtual erase block, each with a particular erase block address toerase a particular erase block. Simultaneously a particular bank (e.g.bank-0 214 a) is selected over the storage control bus 212 to preventerasure of similarly addressed erase blocks in all of the banks (banks1-N 214 b-n). Other commands may also be sent to a particular locationusing a combination of the storage I/O bus 210 and the storage controlbus 212. One of skill in the art will recognize other ways to select aparticular storage location using the bi-directional storage I/O bus 210and the storage control bus 212.

In one embodiment, packets are written sequentially to the solid-statestorage 110 at an append point that is advanced through banks 214. Forexample, packets are streamed to the storage write buffers of a bank 214a of storage elements 216 and when the buffers are full, the packets areprogrammed to a designated virtual page. Packets then refill the storagewrite buffers and, when full, the packets are written to the nextvirtual page. The next virtual page may be in the same bank 214 a oranother bank (e.g. 214 b). This process continues, virtual page aftervirtual page, typically until a virtual erase block is filled. Inanother embodiment, the streaming may continue across virtual eraseblock boundaries with the process continuing, virtual erase block aftervirtual erase block.

In a read, modify, write operation, data packets associated with theobject are located and read in a read operation. Data segments of themodified object that have been modified are not written to the locationfrom which they are read. Instead, the modified data segments are againconverted to data packets and then written to the next availablelocation in the virtual page currently being written. The object indexentries for the respective data packets are modified to point to thepackets that contain the modified data segments. The entry or entries inthe object index for data packets associated with the same object thathave not been modified will include pointers to original location of theunmodified data packets. Thus, if the original object is maintained, forexample to maintain a previous version of the object, the originalobject will have pointers in the object index to all data packets asoriginally written. The new object will have pointers in the objectindex to some of the original data packets and pointers to the modifieddata packets in the virtual page that is currently being written.

In a copy operation, the object index includes an entry for the originalobject mapped to a number of packets stored in the solid-state storage110. When a copy is made, a new object is created and a new entry iscreated in the object index mapping the new object to the originalpackets. The new object is also written to the solid-state storage 110with its location mapped to the new entry in the object index. The newobject packets may be used to identify the packets within the originalobject that are referenced in case changes have been made in theoriginal object that have not been propagated to the copy and the objectindex is lost or corrupted.

Beneficially, sequentially writing packets facilitates a more even useof the solid-state storage 110 and allows the solid-state storage devicecontroller 202 to monitor storage hot spots and level usage of thevarious virtual pages in the solid-state storage 110. Sequentiallywriting packets also facilitates a powerful, efficient garbagecollection system, which is described in detail below. One of skill inthe art will recognize other benefits of sequential storage of datapackets.

Solid-State Storage Device Controller

In various embodiments, the solid-state storage device controller 202also includes a data bus 204, a local bus 206, a buffer controller 208,buffers 0-N 222 a-n, a master controller 224, a direct memory access(“DMA”) controller 226, a memory controller 228, a dynamic memory array230, a static random memory array 232, a management controller 234, amanagement bus 236, a bridge 238 to a system bus 240, and miscellaneouslogic 242, which are described below. In other embodiments, the systembus 240 is coupled to one or more network interface cards (“NICs”) 244,some of which may include remote DMA (“RDMA”) controllers 246, one ormore central processing units (CPUs) 248, one or more external memorycontrollers 250 and associated external memory arrays 252, one or morestorage controllers 254, peer controllers 256, and application specificprocessors 258, which are described below. The components 244-258connected to the system bus 240 may be located in the computer 112 ormay be other devices.

Typically the solid-state storage controller(s) 104 communicate data tothe solid-state storage 110 over a storage I/O bus 210. In a typicalembodiment where the solid-state storage is arranged in banks 214 andeach bank 214 includes multiple storage elements 216, 218, 220 accessedin parallel, the storage I/O bus 210 is an array of busses, one for eachrow of storage elements 216, 218, 220 spanning the banks 214. As usedherein, the term “storage I/O bus” may refer to one storage I/O bus 210or an array of data independent busses 204. In a preferred embodiment,each storage I/O bus 210 accessing a row of storage elements (e.g. 216a, 218 a, 220 a) may include a logical-to-physical mapping for storagedivisions (e.g. erase blocks) accessed in a row of storage elements 216a, 218 a, 220 a. This mapping allows a logical address mapped to aphysical address of a storage division to be remapped to a differentstorage division if the first storage division fails, partially fails,is inaccessible, or has some other problem. Remapping is explainedfurther in relation to the remapping module 430 of FIGS. 4A and 4B.

Data may also be communicated to the solid-state storage controller(s)104 from a requesting device 155 through the system bus 240, bridge 238,local bus 206, buffer(s) 22, and finally over a data bus 204. The databus 204 typically is connected to one or more buffers 222 a-n controlledwith a buffer controller 208. The buffer controller 208 typicallycontrols transfer of data from the local bus 206 to the buffers 222 andthrough the data bus 204 to the pipeline input buffer 306 and outputbuffer 330. The buffer controller 222 typically controls how dataarriving from a requesting device can be temporarily stored in a buffer222 and then transferred onto a data bus 204, or vice versa, to accountfor different clock domains, to prevent data collisions, etc. The buffercontroller 208 typically works in conjunction with the master controller224 to coordinate data flow. As data arrives, the data will arrive onthe system bus 240, be transferred to the local bus 206 through a bridge238.

Typically the data is transferred from the local bus 206 to one or moredata buffers 222 as directed by the master controller 224 and the buffercontroller 208. The data then flows out of the buffer(s) 222 to the databus 204, through a solid-state controller 104, and on to the solid-statestorage 110 such as NAND flash or other storage media. In a preferredembodiment, data and associated out-of-band metadata (“object metadata”)arriving with the data is communicated using one or more data channelscomprising one or more solid-state storage controllers 104 a-104 n−1 andassociated solid-state storage 110 a-110 n−1 while at least one channel(solid-state storage controller 104 n, solid-state storage 110 n) isdedicated to in-band metadata, such as index information and othermetadata generated internally to the solid-state storage device 102.

The local bus 206 is typically a bidirectional bus or set of busses thatallows for communication of data and commands between devices internalto the solid-state storage device controller 202 and between devicesinternal to the solid-state storage device 102 and devices 244-258connected to the system bus 240. The bridge 238 facilitatescommunication between the local bus 206 and system bus 240. One of skillin the art will recognize other embodiments such as ring structures orswitched star configurations and functions of buses 240, 206, 204, 210and bridges 238.

The system bus 240 is typically a bus of a computer 112 or other devicein which the solid-state storage device 102 is installed or connected.In one embodiment, the system bus 240 may be a PCI-e bus, a SerialAdvanced Technology Attachment (“serial ATA”) bus, parallel ATA, or thelike. In another embodiment, the system bus 240 is an external bus suchas small computer system interface (“SCSI”), FireWire, Fiber Channel,USB, PCIe-AS, or the like. The solid-state storage device 102 may bepackaged to fit internally to a device or as an externally connecteddevice.

The solid-state storage device controller 202 includes a mastercontroller 224 that controls higher-level functions within thesolid-state storage device 102. The master controller 224, in variousembodiments, controls data flow by interpreting object requests andother requests, directs creation of indexes to map object identifiersassociated with data to physical locations of associated data,coordinating DMA requests, etc. Many of the functions described hereinare controlled wholly or in part by the master controller 224.

In one embodiment, the master controller 224 uses embeddedcontroller(s). In another embodiment, the master controller 224 useslocal memory such as a dynamic memory array 230 (dynamic random accessmemory “DRAM”), a static memory array 232 (static random access memory“SRAM”), etc. In one embodiment, the local memory is controlled usingthe master controller 224. In another embodiment, the master controller224 accesses the local memory via a memory controller 228. In anotherembodiment, the master controller 224 runs a Linux server and maysupport various common server interfaces, such as the World Wide Web,hyper-text markup language (“HTML”), etc. In another embodiment, themaster controller 224 uses a nano-processor. The master controller 224may be constructed using programmable or standard logic, or anycombination of controller types listed above. One skilled in the artwill recognize many embodiments for the master controller 224.

In one embodiment, where the storage controller 152/solid-state storagedevice controller 202 manages multiple data storage devices/solid-statestorage 110 a-n, the master controller 224 divides the work load amonginternal controllers, such as the solid-state storage controllers 104a-n. For example, the master controller 224 may divide an object to bewritten to the data storage devices (e.g. solid-state storage 110 a-n)so that a portion of the object is stored on each of the attached datastorage devices. This feature is a performance enhancement allowingquicker storage and access to an object. In one embodiment, the mastercontroller 224 is implemented using an FPGA. In another embodiment, thefirmware within the master controller 224 may be updated through themanagement bus 236, the system bus 240 over a network connected to a NIC244 or other device connected to the system bus 240.

In one embodiment, the master controller 224, which manages objects,emulates block storage such that a computer 112 or other deviceconnected to the storage device/solid-state storage device 102 views thestorage device/solid-state storage device 102 as a block storage deviceand sends data to specific physical addresses in the storagedevice/solid-state storage device 102. The master controller 224 thendivides up the blocks and stores the data blocks as it would objects.The master controller 224 then maps the blocks and physical address sentwith the block to the actual locations determined by the mastercontroller 224. The mapping is stored in the object index. Typically,for block emulation, a block device application program interface(“API”) is provided in a driver in the computer 112, client 114, orother device wishing to use the storage device/solid-state storagedevice 102 as a block storage device.

In another embodiment, the master controller 224 coordinates with NICcontrollers 244 and embedded RDMA controllers 246 to deliverjust-in-time RDMA transfers of data and command sets. NIC controller 244may be hidden behind a non-transparent port to enable the use of customdrivers. Also, a driver on a client 114 may have access to the computernetwork 116 through an I/O memory driver using a standard stack API andoperating in conjunction with NICs 244.

In one embodiment, the master controller 224 is also a redundant arrayof independent drive (“RAID”) controller. Where the data storagedevice/solid-state storage device 102 is networked with one or moreother data storage devices/solid-state storage devices 102, the mastercontroller 224 may be a RAID controller for single tier RAID, multi-tierRAID, progressive RAID, etc. The master controller 224 also allows someobjects to be stored in a RAID array and other objects to be storedwithout RAID. In another embodiment, the master controller 224 may be adistributed RAID controller element. In another embodiment, the mastercontroller 224 may comprise many RAID, distributed RAID, and otherfunctions as described elsewhere.

In one embodiment, the master controller 224 coordinates with single orredundant network managers (e.g. switches) to establish routing, tobalance bandwidth utilization, failover, etc. In another embodiment, themaster controller 224 coordinates with integrated application specificlogic (via local bus 206) and associated driver software. In anotherembodiment, the master controller 224 coordinates with attachedapplication specific processors 258 or logic (via the external systembus 240) and associated driver software. In another embodiment, themaster controller 224 coordinates with remote application specific logic(via the computer network 116) and associated driver software. Inanother embodiment, the master controller 224 coordinates with the localbus 206 or external bus attached hard disk drive (“HDD”) storagecontroller.

In one embodiment, the master controller 224 communicates with one ormore storage controllers 254 where the storage device/solid-statestorage device 102 may appear as a storage device connected through aSCSI bus, Internet SCSI (“iSCSI”), fiber channel, etc. Meanwhile thestorage device/solid-state storage device 102 may autonomously manageobjects and may appear as an object file system or distributed objectfile system. The master controller 224 may also be accessed by peercontrollers 256 and/or application specific processors 258.

In another embodiment, the master controller 224 coordinates with anautonomous integrated management controller to periodically validateFPGA code and/or controller software, validate FPGA code while running(reset) and/or validate controller software during power on (reset),support external reset requests, support reset requests due to watchdogtimeouts, and support voltage, current, power, temperature, and otherenvironmental measurements and setting of threshold interrupts. Inanother embodiment, the master controller 224 manages garbage collectionto free erase blocks for reuse. In another embodiment, the mastercontroller 224 manages wear leveling. In another embodiment, the mastercontroller 224 allows the data storage device/solid-state storage device102 to be partitioned into multiple virtual devices and allowspartition-based media encryption. In yet another embodiment, the mastercontroller 224 supports a solid-state storage controller 104 withadvanced, multi-bit ECC correction. One of skill in the art willrecognize other features and functions of a master controller 224 in astorage controller 152, or more specifically in a solid-state storagedevice 102.

In one embodiment, the solid-state storage device controller 202includes a memory controller 228 which controls a dynamic random memoryarray 230 and/or a static random memory array 232. As stated above, thememory controller 228 may be independent or integrated with the mastercontroller 224. The memory controller 228 typically controls volatilememory of some type, such as DRAM (dynamic random memory array 230) andSRAM (static random memory array 232). In other examples, the memorycontroller 228 also controls other memory types such as electricallyerasable programmable read only memory (“EEPROM”), etc. In otherembodiments, the memory controller 228 controls two or more memory typesand the memory controller 228 may include more than one controller.Typically, the memory controller 228 controls as much SRAM 232 as isfeasible and by DRAM 230 to supplement the SRAM 232.

In one embodiment, the object index is stored in memory 230, 232 andthen periodically off-loaded to a channel of the solid-state storage 110n or other non-volatile memory. One of skill in the art will recognizeother uses and configurations of the memory controller 228, dynamicmemory array 230, and static memory array 232.

In one embodiment, the solid-state storage device controller 202includes a DMA controller 226 that controls DMA operations between thestorage device/solid-state storage device 102 and one or more externalmemory controllers 250 and associated external memory arrays 252 andCPUs 248. Note that the external memory controllers 250 and externalmemory arrays 252 are called external because they are external to thestorage device/solid-state storage device 102. In addition the DMAcontroller 226 may also control RDMA operations with requesting devicesthrough a NIC 244 and associated RDMA controller 246. DMA and RDMA areexplained in more detail below.

In one embodiment, the solid-state storage device controller 202includes a management controller 234 connected to a management bus 236.Typically the management controller 234 manages environmental metricsand status of the storage device/solid-state storage device 102. Themanagement controller 234 may monitor device temperature, fan speed,power supply settings, etc. over the management bus 236. The managementcontroller 234 may support the reading and programming of erasableprogrammable read only memory (“EEPROM”) for storage of FPGA code andcontroller software. Typically the management bus 236 is connected tothe various components within the storage device/solid-state storagedevice 102. The management controller 234 may communicate alerts,interrupts, etc. over the local bus 206 or may include a separateconnection to a system bus 240 or other bus. In one embodiment themanagement bus 236 is an Inter-Integrated Circuit (“I²C”) bus. One ofskill in the art will recognize other related functions and uses of amanagement controller 234 connected to components of the storagedevice/solid-state storage device 102 by a management bus 236.

In one embodiment, the solid-state storage device controller 202includes miscellaneous logic 242 that may be customized for a specificapplication. Typically where the solid-state device controller 202 ormaster controller 224 is/are configured using a FPGA or otherconfigurable controller, custom logic may be included based on aparticular application, customer requirement, storage requirement, etc.

Data Pipeline

FIG. 3 is a schematic block diagram illustrating one embodiment 300 of asolid-state storage controller 104 with a write data pipeline 106 and aread data pipeline 108 in a solid-state storage device 102 in accordancewith the present invention. The embodiment 300 includes a data bus 204,a local bus 206, and buffer control 208, which are substantially similarto those described in relation to the solid-state storage devicecontroller 202 of FIG. 2. The write data pipeline 106 includes apacketizer 302 and an error-correcting code (“ECC”) generator 304. Inother embodiments, the write data pipeline 106 includes an input buffer306, a write synchronization buffer 308, a write program module 310, acompression module 312, an encryption module 314, a garbage collectorbypass 316 (with a portion within the read data pipeline 108), a mediaencryption module 318, and a write buffer 320. The read data pipeline108 includes a read synchronization buffer 328, an ECC correction module322, a depacketizer 324, an alignment module 326, and an output buffer330. In other embodiments, the read data pipeline 108 may include amedia decryption module 332, a portion of the garbage collector bypass316, a decryption module 334, a decompression module 336, and a readprogram module 338. The solid-state storage controller 104 may alsoinclude control and status registers 340 and control queues 342, a bankinterleave controller 344, a synchronization buffer 346, a storage buscontroller 348, and a multiplexer (“MUX”) 350. The components of thesolid-state controller 104 and associated write data pipeline 106 andread data pipeline 108 are described below. In other embodiments,synchronous solid-state storage 110 may be used and synchronizationbuffers 308 328 may be eliminated.

Write Data Pipeline

The write data pipeline 106 includes a packetizer 302 that receives adata or metadata segment to be written to the solid-state storage,either directly or indirectly through another write data pipeline 106stage, and creates one or more packets sized for the solid-state storage110. The data or metadata segment is typically part of an object, butmay also include an entire object. In another embodiment, the datasegment is part of a block of data, but may also include an entire blockof data. Typically, an object is received from a computer 112, client114, or other computer or device and is transmitted to the solid-statestorage device 102 in data segments streamed to the solid-state storagedevice 102 or computer 112. A data segment may also be known by anothername, such as data parcel, but as referenced herein includes all or aportion of an object or data block.

Each object is stored as one or more packets. Each object may have oneor more container packets. Each packet contains a header. The header mayinclude a header type field. Type fields may include data, objectattribute, metadata, data segment delimiters (multi-packet), objectstructures, object linkages, and the like. The header may also includeinformation regarding the size of the packet, such as the number ofbytes of data included in the packet. The length of the packet may beestablished by the packet type. The header may include information thatestablishes the relationship of the packet to the object. An examplemight be the use of an offset in a data packet header to identify thelocation of the data segment within the object. One of skill in the artwill recognize other information that may be included in a header addedto data by a packetizer 302 and other information that may be added to adata packet.

Each packet includes a header and possibly data from the data ormetadata segment. The header of each packet includes pertinentinformation to relate the packet to the object to which the packetbelongs. For example, the header may include an object identifier andoffset that indicates the data segment, object, or data block from whichthe data packet was formed. The header may also include a logicaladdress used by the storage bus controller 348 to store the packet. Theheader may also include information regarding the size of the packet,such as the number of bytes included in the packet. The header may alsoinclude a sequence number that identifies where the data segment belongswith respect to other packets within the object when reconstructing thedata segment or object. The header may include a header type field. Typefields may include data, object attributes, metadata, data segmentdelimiters (multi-packet), object structures, object linkages, and thelike. One of skill in the art will recognize other information that maybe included in a header added to data or metadata by a packetizer 302and other information that may be added to a packet.

The write data pipeline 106 includes an ECC generator 304 that generatesone or more error-correcting codes (“ECC”) for the one or more packetsreceived from the packetizer 302. The ECC generator 304 typically usesan error correcting algorithm to generate ECC which is stored with thepacket. The ECC stored with the packet is typically used to detect andcorrect errors introduced into the data through transmission andstorage. In one embodiment, packets are streamed into the ECC generator304 as un-encoded blocks of length N. A syndrome of length S iscalculated, appended and output as an encoded block of length N+S. Thevalue of N and S are dependent upon the characteristics of the algorithmwhich is selected to achieve specific performance, efficiency, androbustness metrics. In the preferred embodiment, there is no fixedrelationship between the ECC blocks and the packets; the packet maycomprise more than one ECC block; the ECC block may comprise more thanone packet; and a first packet may end anywhere within the ECC block anda second packet may begin after the end of the first packet within thesame ECC block. In the preferred embodiment, ECC algorithms are notdynamically modified. In a preferred embodiment, the ECC stored with thedata packets is robust enough to correct errors in more than two bits.

Beneficially, using a robust ECC algorithm allowing more than single bitcorrection or even double bit correction allows the life of thesolid-state storage 110 to be extended. For example, if flash memory isused as the storage medium in the solid-state storage 110, the flashmemory may be written approximately 100,000 times without error pererase cycle. This usage limit may be extended using a robust ECCalgorithm. Having the ECC generator 304 and corresponding ECC correctionmodule 322 onboard the solid-state storage device 102, the solid-statestorage device 102 can internally correct errors and has a longer usefullife than if a less robust ECC algorithm is used, such as single bitcorrection. However, in other embodiments the ECC generator 304 may usea less robust algorithm and may correct single-bit or double-bit errors.In another embodiment, the solid-state storage device 110 may compriseless reliable storage such as multi-level cell (“MLC”) flash in order toincrease capacity, which storage may not be sufficiently reliablewithout more robust ECC algorithms.

In one embodiment, the write pipeline 106 includes an input buffer 306that receives a data segment to be written to the solid-state storage110 and stores the incoming data segments until the next stage of thewrite data pipeline 106, such as the packetizer 302 (or other stage fora more complex write data pipeline 106) is ready to process the nextdata segment. The input buffer 306 typically allows for discrepanciesbetween the rate data segments are received and processed by the writedata pipeline 106 using an appropriately sized data buffer. The inputbuffer 306 also allows the data bus 204 to transfer data to the writedata pipeline 106 at rates greater than can be sustained by the writedata pipeline 106 in order to improve efficiency of operation of thedata bus 204. Typically when the write data pipeline 106 does notinclude an input buffer 306, a buffering function is performedelsewhere, such as in the solid-state storage device 102 but outside thewrite data pipeline 106, in the computer 112, such as within a networkinterface card (“NIC”), or at another device, for example when usingremote direct memory access (“RDMA”).

In another embodiment, the write data pipeline 106 also includes a writesynchronization buffer 308 that buffers packets received from the ECCgenerator 304 prior to writing the packets to the solid-state storage110. The write synch buffer 308 is located at a boundary between a localclock domain and a solid-state storage clock domain and providesbuffering to account for the clock domain differences. In otherembodiments, synchronous solid-state storage 110 may be used andsynchronization buffers 308, 328 may be eliminated.

In one embodiment, the write data pipeline 106 also includes a mediaencryption module 318 that receives the one or more packets from thepacketizer 302, either directly or indirectly, and encrypts the one ormore packets using an encryption key unique to the solid-state storagedevice 102 prior to sending the packets to the ECC generator 304.Typically, the entire packet is encrypted, including the headers. Inanother embodiment, headers are not encrypted. In this document,encryption key is understood to mean a secret encryption key that ismanaged externally from an embodiment that integrates the solid-statestorage 110 and where the embodiment requires encryption protection. Themedia encryption module 318 and corresponding media decryption module332 provide a level of security for data stored in the solid-statestorage 110. For example, where data is encrypted with the mediaencryption module 318, if the solid-state storage 110 is connected to adifferent solid-state storage controller 104, solid-state storage device102, or computer 112, the contents of the solid-state storage 110typically could not be read without use of the same encryption key usedduring the write of the data to the solid-state storage 110 withoutsignificant effort.

In a typical embodiment, the solid-state storage device 102 does notstore the encryption key in non-volatile storage and allows no externalaccess to the encryption key. The encryption key is provided to thesolid-state storage controller 104 during initialization. Thesolid-state storage device 102 may use and store a non-secretcryptographic nonce that is used in conjunction with an encryption key.A different nonce may be stored with every packet. Data segments may besplit between multiple packets with unique nonces for the purpose ofimproving protection by the encryption algorithm. The encryption key maybe received from a client 114, a computer 112, key manager, or otherdevice that manages the encryption key to be used by the solid-statestorage controller 104. In another embodiment, the solid-state storage110 may have two or more partitions and the solid-state storagecontroller 104 behaves as though it were two or more solid-state storagecontrollers 104, each operating on a single partition within thesolid-state storage 110. In this embodiment, a unique media encryptionkey may be used with each partition.

In another embodiment, the write data pipeline 106 also includes anencryption module 314 that encrypts a data or metadata segment receivedfrom the input buffer 306, either directly or indirectly, prior sendingthe data segment to the packetizer 302, the data segment is encryptedusing an encryption key received in conjunction with the data segment.The encryption module 314 differs from the media encryption module 318in that the encryption keys used by the encryption module 318 to encryptdata may not be common to all data stored within the solid-state storagedevice 102 but may vary on an object basis and received in conjunctionwith receiving data segments as described below. For example, anencryption key for a data segment to be encrypted by the encryptionmodule 318 may be received with the data segment or may be received aspart of a command to write an object to which the data segment belongs.The solid-state storage device 102 may use and store a non-secretcryptographic nonce in each object packet that is used in conjunctionwith the encryption key. A different nonce may be stored with everypacket. Data segments may be split between multiple packets with uniquenonces for the purpose of improving protection by the encryptionalgorithm. In one embodiment, the nonce used by the media encryptionmodule 318 is the same as that used by the encryption module 314.

The encryption key may be received from a client 114, a computer 112,key manager, or other device that holds the encryption key to be used toencrypt the data segment. In one embodiment, encryption keys aretransferred to the solid-state storage controller 104 from one of asolid-state storage device 102, computer 112, client 114, or otherexternal agent which has the ability to execute industry standardmethods to securely transfer and protect private and public keys.

In one embodiment, the encryption module 314 encrypts a first packetwith a first encryption key received in conjunction with the packet andencrypts a second packet with a second encryption key received inconjunction with the second packet. In another embodiment, theencryption module 314 encrypts a first packet with a first encryptionkey received in conjunction with the packet and passes a second datapacket on to the next stage without encryption. Beneficially, theencryption module 314 included in the write data pipeline 106 of thesolid-state storage device 102 allows object-by-object orsegment-by-segment data encryption without a single file system or otherexternal system to keep track of the different encryption keys used tostore corresponding objects or data segments. Each requesting device 155or related key manager independently manages encryption keys used toencrypt only the objects or data segments sent by the requesting device155.

In another embodiment, the write data pipeline 106 includes acompression module 312 that compresses the data for or metadata segmentprior to sending the data segment to the packetizer 302. The compressionmodule 312 typically compresses a data or metadata segment using acompression routine known to those of skill in the art to reduce thestorage size of the segment. For example, if a data segment includes astring of 512 zeros, the compression module 312 may replace the 512zeros with code or token indicating the 512 zeros where the code is muchmore compact than the space taken by the 512 zeros.

In one embodiment, the compression module 312 compresses a first segmentwith a first compression routine and passes along a second segmentwithout compression. In another embodiment, the compression module 312compresses a first segment with a first compression routine andcompresses the second segment with a second compression routine. Havingthis flexibility within the solid-state storage device 102 is beneficialso that clients 114 or other devices writing data to the solid-statestorage device 102 may each specify a compression routine or so that onecan specify a compression routine while another specifies nocompression. Selection of compression routines may also be selectedaccording to default settings on a per object type or object classbasis. For example, a first object of a specific object class and typemay be able to override default compression routine settings and asecond object of the same object class and object type may use thedefault compression routine and a third object of the same object classand object type may use no compression.

In one embodiment, the write data pipeline 106 includes a garbagecollector bypass 316 that receives data segments from the read datapipeline 108 as part of a data bypass in a garbage collection system. Agarbage collection system typically marks packets that are no longervalid, typically because the packet is marked for deletion or has beenmodified and the modified data is stored in a different location. Atsome point, the garbage collection system determines that a particularsection of storage may be recovered. This determination may be due to alack of available storage capacity, the percentage of data marked asinvalid reaching a threshold, a consolidation of valid data, an errordetection rate for that section of storage reaching a threshold, orimproving performance based on data distribution, etc. Numerous factorsmay be considered by a garbage collection algorithm to determine when asection of storage is to be recovered.

Once a section of storage has been marked for recovery, valid packets inthe section typically must be relocated. The garbage collector bypass316 allows packets to be read into the read data pipeline 108 and thentransferred directly to the write data pipeline 106 without being routedout of the solid-state storage controller 104. In a preferredembodiment, the garbage collector bypass 316 is part of an autonomousgarbage collector system that operates within the solid-state storagedevice 102. This allows the solid-state storage device 102 to managedata so that data is systematically spread throughout the solid-statestorage 110 to improve performance, data reliability and to avoidoveruse and underuse of any one location or area of the solid-statestorage 110 and to lengthen the useful life of the solid-state storage110.

The garbage collector bypass 316 coordinates insertion of segments intothe write data pipeline 106 with other segments being written by clients114 or other devices. In the depicted embodiment, the garbage collectorbypass 316 is before the packetizer 302 in the write data pipeline 106and after the depacketizer 324 in the read data pipeline 108, but mayalso be located elsewhere in the read and write data pipelines 106, 108.The garbage collector bypass 316 may be used during a flush of the writepipeline 106 to fill the remainder of the virtual page in order toimprove the efficiency of storage within the Solid-State Storage 110 andthereby reduce the frequency of garbage collection.

In one embodiment, the write data pipeline 106 includes a write buffer320 that buffers data for efficient write operations. Typically, thewrite buffer 320 includes enough capacity for packets to fill at leastone virtual page in the solid-state storage 110. This allows a writeoperation to send an entire page of data to the solid-state storage 110without interruption. By sizing the write buffer 320 of the write datapipeline 106 and buffers within the read data pipeline 108 to be thesame capacity or larger than a storage write buffer within thesolid-state storage 110, writing and reading data is more efficientsince a single write command may be crafted to send a full virtual pageof data to the solid-state storage 110 instead of multiple commands.

While the write buffer 320 is being filled, the solid-state storage 110may be used for other read operations. This is advantageous becauseother solid-state devices with a smaller write buffer or no write buffermay tie up the solid-state storage when data is written to a storagewrite buffer and data flowing into the storage write buffer stalls. Readoperations will be blocked until the entire storage write buffer isfilled and programmed. Another approach for systems without a writebuffer or a small write buffer is to flush the storage write buffer thatis not full in order to enable reads. Again this is inefficient becausemultiple write/program cycles are required to fill a page.

For the depicted embodiment with a write buffer 320 sized larger than avirtual page, a single write command, which includes numeroussubcommands, can then be followed by a single program command totransfer the page of data from the storage write buffer in eachsolid-state storage element 216, 218, 220 to the designated page withineach solid-state storage element 216, 218, 220. This technique has thebenefits of eliminating partial page programming, which is known toreduce data reliability and durability and freeing up the destinationbank for reads and other commands while the buffer fills.

In one embodiment, the write buffer 320 is a ping-pong buffer where oneside of the buffer is filled and then designated for transfer at anappropriate time while the other side of the ping-pong buffer is beingfilled. In another embodiment, the write buffer 320 includes a first-infirst-out (“FIFO”) register with a capacity of more than a virtual pageof data segments. One of skill in the art will recognize other writebuffer 320 configurations that allow a virtual page of data to be storedprior to writing the data to the solid-state storage 110.

In another embodiment, the write buffer 320 is sized smaller than avirtual page so that less than a page of information could be written toa storage write buffer in the solid-state storage 110. In theembodiment, to prevent a stall in the write data pipeline 106 fromholding up read operations, data is queued using the garbage collectionsystem that needs to be moved from one location to another as part ofthe garbage collection process. In case of a data stall in the writedata pipeline 106, the data can be fed through the garbage collectorbypass 316 to the write buffer 320 and then on to the storage writebuffer in the solid-state storage 110 to fill the pages of a virtualpage prior to programming the data. In this way a data stall in thewrite data pipeline 106 would not stall reading from the solid-statestorage device 102.

In another embodiment, the write data pipeline 106 includes a writeprogram module 310 with one or more user-definable functions within thewrite data pipeline 106. The write program module 310 allows a user tocustomize the write data pipeline 106. A user may customize the writedata pipeline 106 based on a particular data requirement or application.Where the solid-state storage controller 104 is an FPGA, the user mayprogram the write data pipeline 106 with custom commands and functionsrelatively easily. A user may also use the write program module 310 toinclude custom functions with an ASIC, however, customizing an ASIC maybe more difficult than with an FPGA. The write program module 310 mayinclude buffers and bypass mechanisms to allow a first data segment toexecute in the write program module 310 while a second data segment maycontinue through the write data pipeline 106. In another embodiment, thewrite program module 310 may include a processor core that can beprogrammed through software.

Note that the write program module 310 is shown between the input buffer306 and the compression module 312, however, the write program module310 could be anywhere in the write data pipeline 106 and may bedistributed among the various stages 302-320. In addition, there may bemultiple write program modules 310 distributed among the various states302-320 that are programmed and operate independently. In addition, theorder of the stages 302-320 may be altered. One of skill in the art willrecognize workable alterations to the order of the stages 302-320 basedon particular user requirements.

Read Data Pipeline

The read data pipeline 108 includes an ECC correction module 322 thatdetermines if a data error exists in the ECC blocks of a requestedpacket received from the solid-state storage 110 by using the ECC storedwith each ECC block of the requested packet. The ECC correction module322 then corrects any errors in the requested packet if any error existsand the errors are correctable using the ECC. For example, if the ECCcan detect an error in six bits but can only correct three bit errors,the ECC correction module 322 corrects ECC blocks of the requestedpacket with up to three bits in error. The ECC correction module 322corrects the bits in error by changing the bits in error to the correctone or zero state so that the requested data packet is identical to whenit was written to the solid-state storage 110 and the ECC was generatedfor the packet.

If the ECC correction module 322 determines that the requested packetscontains more bits in error than the ECC can correct, the ECC correctionmodule 322 cannot correct the errors in the corrupted ECC blocks of therequested packet and sends an interrupt. In one embodiment, the ECCcorrection module 322 sends an interrupt with a message indicating thatthe requested packet is in error. The message may include informationthat the ECC correction module 322 cannot correct the errors or theinability of the ECC correction module 322 to correct the errors may beimplied. In another embodiment, the ECC correction module 322 sends thecorrupted ECC blocks of the requested packet with the interrupt and/orthe message.

In the preferred embodiment, a corrupted ECC block or portion of acorrupted ECC block of the requested packet that cannot be corrected bythe ECC correction module 322 is read by the master controller 224,corrected, and returned to the ECC correction module 322 for furtherprocessing by the read data pipeline 108. In one embodiment, a corruptedECC block or portion of a corrupted ECC block of the requested packet issent to the device requesting the data. The requesting device 155 maycorrect the ECC block or replace the data using another copy, such as abackup or mirror copy, and then may use the replacement data of therequested data packet or return it to the read data pipeline 108. Therequesting device 155 may use header information in the requested packetin error to identify data required to replace the corrupted requestedpacket or to replace the object to which the packet belongs. In anotherpreferred embodiment, the solid-state storage controller 104 stores datausing some type of RAID and is able to recover the corrupted data. Inanother embodiment, the ECC correction module 322 sends an interruptand/or message and the receiving device fails the read operationassociated with the requested data packet. One of skill in the art willrecognize other options and actions to be taken as a result of the ECCcorrection module 322 determining that one or more ECC blocks of therequested packet are corrupted and that the ECC correction module 322cannot correct the errors.

The read data pipeline 108 includes a depacketizer 324 that receives ECCblocks of the requested packet from the ECC correction module 322,directly or indirectly, and checks and removes one or more packetheaders. The depacketizer 324 may validate the packet headers bychecking packet identifiers, data length, data location, etc. within theheaders. In one embodiment, the header includes a hash code that can beused to validate that the packet delivered to the read data pipeline 108is the requested packet. The depacketizer 324 also removes the headersfrom the requested packet added by the packetizer 302. The depacketizer324 may be directed to not operate on certain packets but pass theseforward without modification. An example might be a container label thatis requested during the course of a rebuild process where the headerinformation is required by the object index reconstruction module 272.Further examples include the transfer of packets of various typesdestined for use within the solid-state storage device 102. In anotherembodiment, the depacketizer 324 operation may be packet type dependent.

The read data pipeline 108 includes an alignment module 326 thatreceives data from the depacketizer 324 and removes unwanted data. Inone embodiment, a read command sent to the solid-state storage 110retrieves a packet of data. A device requesting the data may not requireall data within the retrieved packet and the alignment module 326removes the unwanted data. If all data within a retrieved page isrequested data, the alignment module 326 does not remove any data.

The alignment module 326 re-formats the data as data segments of anobject in a form compatible with a device requesting the data segmentprior to forwarding the data segment to the next stage. Typically, asdata is processed by the read data pipeline 108, the size of datasegments or packets changes at various stages. The alignment module 326uses received data to format the data into data segments suitable to besent to the requesting device 155 and joined to form a response. Forexample, data from a portion of a first data packet may be combined withdata from a portion of a second data packet. If a data segment is largerthan a data requested by the requesting device 155, the alignment module326 may discard the unwanted data.

In one embodiment, the read data pipeline 108 includes a readsynchronization buffer 328 that buffers one or more requested packetsread from the solid-state storage 110 prior to processing by the readdata pipeline 108. The read synchronization buffer 328 is at theboundary between the solid-state storage clock domain and the local busclock domain and provides buffering to account for the clock domaindifferences.

In another embodiment, the read data pipeline 108 includes an outputbuffer 330 that receives requested packets from the alignment module 326and stores the packets prior to transmission to the requesting device155. The output buffer 330 accounts for differences between when datasegments are received from stages of the read data pipeline 108 and whenthe data segments are transmitted to other parts of the solid-statestorage controller 104 or to the requesting device 155. The outputbuffer 330 also allows the data bus 204 to receive data from the readdata pipeline 108 at rates greater than can be sustained by the readdata pipeline 108 in order to improve efficiency of operation of thedata bus 204.

In one embodiment, the read data pipeline 108 includes a mediadecryption module 332 that receives one or more encrypted requestedpackets from the ECC correction module 322 and decrypts the one or morerequested packets using the encryption key unique to the solid-statestorage device 102 prior to sending the one or more requested packets tothe depacketizer 324. Typically the encryption key used to decrypt databy the media decryption module 332 is identical to the encryption keyused by the media encryption module 318. In another embodiment, thesolid-state storage 110 may have two or more partitions and thesolid-state storage controller 104 behaves as though it were two or moresolid-state storage controllers 104 each operating on a single partitionwithin the solid-state storage 110. In this embodiment, a unique mediaencryption key may be used with each partition.

In another embodiment, the read data pipeline 108 includes a decryptionmodule 334 that decrypts a data segment formatted by the depacketizer324 prior to sending the data segment to the output buffer 330. The datasegment decrypted using an encryption key received in conjunction withthe read request that initiates retrieval of the requested packetreceived by the read synchronization buffer 328. The decryption module334 may decrypt a first packet with an encryption key received inconjunction with the read request for the first packet and then maydecrypt a second packet with a different encryption key or may pass thesecond packet on to the next stage of the read data pipeline 108 withoutdecryption. Typically, the decryption module 334 uses a differentencryption key to decrypt a data segment than the media decryptionmodule 332 uses to decrypt requested packets. When the packet was storedwith a non-secret cryptographic nonce, the nonce is used in conjunctionwith an encryption key to decrypt the data packet. The encryption keymay be received from a client 114, a computer 112, key manager, or otherdevice that manages the encryption key to be used by the solid-statestorage controller 104.

In another embodiment, the read data pipeline 108 includes adecompression module 336 that decompresses a data segment formatted bythe depacketizer 324. In the preferred embodiment, the decompressionmodule 336 uses compression information stored in one or both of thepacket header and the container label to select a complementary routineto that used to compress the data by the compression module 312. Inanother embodiment, the decompression routine used by the decompressionmodule 336 is dictated by the device requesting the data segment beingdecompressed. In another embodiment, the decompression module 336selects a decompression routine according to default settings on a perobject type or object class basis. A first packet of a first object maybe able to override a default decompression routine and a second packetof a second object of the same object class and object type may use thedefault decompression routine and a third packet of a third object ofthe same object class and object type may use no decompression.

In another embodiment, the read data pipeline 108 includes a readprogram module 338 that includes one or more user-definable functionswithin the read data pipeline 108. The read program module 338 hassimilar characteristics to the write program module 310 and allows auser to provide custom functions to the read data pipeline 108. The readprogram module 338 may be located as shown in FIG. 3, may be located inanother position within the read data pipeline 108, or may includemultiple parts in multiple locations within the read data pipeline 108.Additionally, there may be multiple read program modules 338 withinmultiple locations within the read data pipeline 108 that operateindependently. One of skill in the art will recognize other forms of aread program module 338 within a read data pipeline 108. As with thewrite data pipeline 106, the stages of the read data pipeline 108 may berearranged and one of skill in the art will recognize other orders ofstages within the read data pipeline 108.

The solid-state storage controller 104 includes control and statusregisters 340 and corresponding control queues 342. The control andstatus registers 340 and control queues 342 facilitate control andsequencing commands and subcommands associated with data processed inthe write and read data pipelines 106, 108. For example, a data segmentin the packetizer 302 may have one or more corresponding controlcommands or instructions in a control queue 342 associated with the ECCgenerator 304. As the data segment is packetized, some of theinstructions or commands may be executed within the packetizer 302.Other commands or instructions may be passed to the next control queue342 through the control and status registers 340 as the newly formeddata packet created from the data segment is passed to the next stage.

Commands or instructions may be simultaneously loaded into the controlqueues 342 for a packet being forwarded to the write data pipeline 106with each pipeline stage pulling the appropriate command or instructionas the respective packet is executed by that stage. Similarly, commandsor instructions may be simultaneously loaded into the control queues 342for a packet being requested from the read data pipeline 108 with eachpipeline stage pulling the appropriate command or instruction as therespective packet is executed by that stage. One of skill in the artwill recognize other features and functions of control and statusregisters 340 and control queues 342.

The solid-state storage controller 104 and or solid-state storage device102 may also include a bank interleave controller 344, a synchronizationbuffer 346, a storage bus controller 348, and a multiplexer (“MUX”) 350,which are described in relation to FIGS. 4A and 4B.

Bank Interleave

FIG. 4A is a schematic block diagram illustrating one embodiment 400 ofa bank interleave controller 344 in the solid-state storage controller104 in accordance with the present invention. The bank interleavecontroller 344 is connected to the control and status registers 340 andto the storage I/O bus 210 and storage control bus 212 through the MUX350, storage bus controller 348, and synchronization buffer 346, whichare described below. The bank interleave controller 344 includes a readagent 402, a write agent 404, an erase agent 406, a management agent408, read queues 410 a-n, write queues 412 a-n, erase queues 414 a-n,and management queues 416 a-n for the banks 214 in the solid-statestorage 110, bank controllers 418 a-n, a bus arbiter 420, and a statusMUX 422, which are described below. The storage bus controller 348includes a mapping module 424 with a remapping module 430, a statuscapture module 426, and a NAND bus controller 428, which are describedbelow.

The bank interleave controller 344 directs one or more commands to twoor more queues in the bank interleave controller 344 and coordinatesamong the banks 214 of the solid-state storage 110 execution of thecommands stored in the queues, such that a command of a first typeexecutes on one bank 214 a while a command of a second type executes ona second bank 214 b. The one or more commands are separated by commandtype into the queues. Each bank 214 of the solid-state storage 110 has acorresponding set of queues within the bank interleave controller 344and each set of queues includes a queue for each command type.

The bank interleave controller 344 coordinates among the banks 214 ofthe solid-state storage 110 execution of the commands stored in thequeues. For example, a command of a first type executes on one bank 214a while a command of a second type executes on a second bank 214 b.Typically the command types and queue types include read and writecommands and queues 410, 412, but may also include other commands andqueues that are storage media specific. For example, in the embodimentdepicted in FIG. 4A, erase and management queues 414, 416 are includedand would be appropriate for flash memory, NRAM, MRAM, DRAM, PRAM, etc.

For other types of solid-state storage 110, other types of commands andcorresponding queues may be included without straying from the scope ofthe invention. The flexible nature of an FPGA solid-state storagecontroller 104 allows flexibility in storage media. If flash memory werechanged to another solid-state storage type, the bank interleavecontroller 344, storage bus controller 348, and MUX 350 could be alteredto accommodate the media type without significantly affecting the datapipelines 106, 108 and other solid-state storage controller 104functions.

In the embodiment depicted in FIG. 4A, the bank interleave controller344 includes, for each bank 214, a read queue 410 for reading data fromthe solid-state storage 110, a write queue 412 for write commands to thesolid-state storage 110, an erase queue 414 for erasing an erase blockin the solid-state storage, an a management queue 416 for managementcommands. The bank interleave controller 344 also includes correspondingread, write, erase, and management agents 402, 404, 406, 408. In anotherembodiment, the control and status registers 340 and control queues 342or similar components queue commands for data sent to the banks 214 ofthe solid-state storage 110 without a bank interleave controller 344.

The agents 402, 404, 406, 408, in one embodiment, direct commands of theappropriate type destined for a particular bank 214 a to the correctqueue for the bank 214 a. For example, the read agent 402 may receive aread command for bank-1 214 b and directs the read command to the bank-1read queue 410 b. The write agent 404 may receive a write command towrite data to a location in bank-0 214 a of the solid-state storage 110and will then send the write command to the bank-0 write queue 412 a.Similarly, the erase agent 406 may receive an erase command to erase anerase block in bank-1 214 b and will then pass the erase command to thebank-1 erase queue 414 b. The management agent 408 typically receivesmanagement commands, status requests, and the like, such as a resetcommand or a request to read a configuration register of a bank 214,such as bank-0 214 a. The management agent 408 sends the managementcommand to the bank-0 management queue 416 a.

The agents 402, 404, 406, 408 typically also monitor status of thequeues 410, 412, 414, 416 and send status, interrupt, or other messageswhen the queues 410, 412, 414, 416 are full, nearly full,non-functional, etc. In one embodiment, the agents 402, 404, 406, 408receive commands and generate corresponding sub-commands. In oneembodiment, the agents 402, 404, 406, 408 receive commands through thecontrol & status registers 340 and generate corresponding sub-commandswhich are forwarded to the queues 410, 412, 414, 416. One of skill inthe art will recognize other functions of the agents 402, 404, 406, 408.

The queues 410, 412, 414, 416 typically receive commands and store thecommands until required to be sent to the solid-state storage banks 214.In a typical embodiment, the queues 410, 412, 414, 416 are first-in,first-out (“FIFO”) registers or a similar component that operates as aFIFO. In another embodiment, the queues 410, 412, 414, 416 storecommands in an order that matches data, order of importance, or othercriteria.

The bank controllers 418 typically receive commands from the queues 410,412, 414, 416 and generate appropriate subcommands. For example, thebank-0 write queue 412 a may receive a command to write a page of datapackets to bank-0 214 a. The bank-0 controller 418 a may receive thewrite command at an appropriate time and may generate one or more writesubcommands for each data packet stored in the write buffer 320 to bewritten to the page in bank-0 214 a. For example, bank-0 controller 418a may generate commands to validate the status of bank 0 214 a and thesolid-state storage array 216, select the appropriate location forwriting one or more data packets, clear the input buffers within thesolid-state storage memory array 216, transfer the one or more datapackets to the input buffers, program the input buffers into theselected location, verify that the data was correctly programmed, and ifprogram failures occur do one or more of interrupting the mastercontroller, retrying the write to the same physical location, andretrying the write to a different physical location. Additionally, inconjunction with example write command, the storage bus controller 348will cause the one or more commands to be multiplied to each of thestorage I/O buses 210 a-n with the logical address of the command mappedto a first physical addresses for storage I/O bus 210 a, and mapped to asecond physical address for storage I/O bus 210 b, and so forth asfurther described below.

Typically, bus arbiter 420 selects from among the bank controllers 418and pulls subcommands from output queues within the bank controllers 418and forwards these to the Storage Bus Controller 348 in a sequence thatoptimizes the performance of the banks 214. In another embodiment, thebus arbiter 420 may respond to a high level interrupt and modify thenormal selection criteria. In another embodiment, the master controller224 can control the bus arbiter 420 through the control and statusregisters 340. One of skill in the art will recognize other means bywhich the bus arbiter 420 may control and interleave the sequence ofcommands from the bank controllers 418 to the solid-state storage 110.

The bus arbiter 420 typically coordinates selection of appropriatecommands, and corresponding data when required for the command type,from the bank controllers 418 and sends the commands and data to thestorage bus controller 348. The bus arbiter 420 typically also sendscommands to the storage control bus 212 to select the appropriate bank214. For the case of flash memory or other solid-state storage 110 withan asynchronous, bi-directional serial storage I/O bus 210, only onecommand (control information) or set of data can be transmitted at atime. For example, when write commands or data are being transmitted tothe solid-state storage 110 on the storage I/O bus 210, read commands,data being read, erase commands, management commands, or other statuscommands cannot be transmitted on the storage I/O bus 210. For example,when data is being read from the storage I/O bus 210, data cannot bewritten to the solid-state storage 110.

For example, during a write operation on bank-0 the bus arbiter 420selects the bank-0 controller 418 a which may have a write command or aseries of write sub-u commands on the top of its queue which cause thestorage bus controller 348 to execute the following sequence. The busarbiter 420 forwards the write command to the storage bus controller348, which sets up a write command by selecting bank-0 214 a through thestorage control bus 212, sending a command to clear the input buffers ofthe solid-state storage elements 110 associated with the bank-0 214 a,and sending a command to validate the status of the solid-state storageelements 216, 218, 220 associated with the bank-0 214 a. The storage buscontroller 348 then transmits a write subcommand on the storage I/O bus210, which contains the physical addresses including the address of thelogical erase block for each individual physical erase solid-stagestorage element 216 a-m as mapped from the logical erase block address.The storage bus controller 348 then muxes the write buffer 320 throughthe write sync buffer 308 to the storage I/O bus 210 through the MUX 350and streams write data to the appropriate page. When the page is full,then storage bus controller 348 causes the solid-state storage elements216 a-m associated with the bank-0 214 a to program the input buffer tothe memory cells within the solid-state storage elements 216 a-m.Finally, the storage bus controller 348 validates the status to ensurethat page was correctly programmed.

A read operation is similar to the write example above. During a readoperation, typically the bus arbiter 420, or other component of the bankinterleave controller 344, receives data and corresponding statusinformation and sends the data to the read data pipeline 108 whilesending the status information on to the control and status registers340. Typically, a read data command forwarded from bus arbiter 420 tothe storage bus controller 348 will cause the MUX 350 to gate the readdata on storage I/O bus 210 to the read data pipeline 108 and sendstatus information to the appropriate control and status registers 340through the status MUX 422.

The bus arbiter 420 coordinates the various command types and dataaccess modes so that only an appropriate command type or correspondingdata is on the bus at any given time. If the bus arbiter 420 hasselected a write command, and write subcommands and corresponding dataare being written to the solid-state storage 110, the bus arbiter 420will not allow other command types on the storage I/O bus 210.Beneficially, the bus arbiter 420 uses timing information, such aspredicted command execution times, along with status informationreceived concerning bank 214 status to coordinate execution of thevarious commands on the bus with the goal of minimizing or eliminatingidle time of the busses.

The master controller 224 through the bus arbiter 420 typically usesexpected completion times of the commands stored in the queues 410, 412,414, 416, along with status information, so that when the subcommandsassociated with a command are executing on one bank 214 a, othersubcommands of other commands are executing on other banks 214 b-n. Whenone command is fully executed on a bank 214 a, the bus arbiter 420directs another command to the bank 214 a. The bus arbiter 420 may alsocoordinate commands stored in the queues 410, 412, 414, 416 with othercommands that are not stored in the queues 410, 412, 414, 416.

For example, an erase command may be sent out to erase a group of eraseblocks within the solid-state storage 110. An erase command may take 10to 1000 times more time to execute than a write or a read command or 10to 100 times more time to execute than a program command. For N banks214, the bank interleave controller 344 may split the erase command intoN commands, each to erase a virtual erase block of a bank 214 a. Whilebank-0 214 a is executing an erase command, the bus arbiter 420 mayselect other commands for execution on the other banks 214 b-n. The busarbiter 420 may also work with other components, such as the storage buscontroller 348, the master controller 224, etc., to coordinate commandexecution among the buses. Coordinating execution of commands using thebus arbiter 420, bank controllers 418, queues 410, 412, 414, 416, andagents 402, 404, 406, 408 of the bank interleave controller 344 candramatically increase performance over other solid-state storage systemswithout a bank interleave function.

In one embodiment, the solid-state controller 104 includes one bankinterleave controller 344 that serves all of the storage elements 216,218, 220 of the solid-state storage 110. In another embodiment, thesolid-state controller 104 includes a bank interleave controller 344 foreach row of storage elements 216 a-m, 218 a-m, 220 a-m. For example, onebank interleave controller 344 serves one row of storage elements SSS0.0-SSS 0.N 216 a, 218 a, 220 a, a second bank interleave controller 344serves a second row of storage elements SSS 1.0-SSS 1.N 216 b, 218 b,220 b, etc.

FIG. 4B is a schematic block diagram illustrating an alternateembodiment 401 of a bank interleave controller 344 in the solid-statestorage controller 104 in accordance with the present invention. Thecomponents 210, 212, 340, 346, 348, 350, 402-430 depicted in theembodiment shown in FIG. 4B are substantially similar to the bankinterleave apparatus 400 described in relation to FIG. 4A except thateach bank 214 includes a single queue 432 a-n and the read commands,write commands, erase commands, management commands, etc. for a bank(e.g. Bank-0 214 a) are directed to a single queue 432 a for the bank214 a. The queues 432, in one embodiment, are FIFO. In anotherembodiment, the queues 432 can have commands pulled from the queues 432in an order other than the order they were stored. In another alternateembodiment (not shown), the read agent 402, write agent 404, erase agent406, and management agent 408 may be combined into a single agentassigning commands to the appropriate queues 432 a-n.

In another alternate embodiment (not shown), commands are stored in asingle queue where the commands may be pulled from the queue in an orderother than how they are stored so that the bank interleave controller344 can execute a command on one bank 214 a while other commands areexecuting on the remaining banks 214 b-n. One of skill in the art willeasily recognize other queue configurations and types to enableexecution of a command on one bank 214 a while other commands areexecuting on other banks 214 b-n.

Storage-Specific Components

The solid-state storage controller 104 includes a synchronization buffer346 that buffers commands and status messages sent and received from thesolid-state storage 110. The synchronization buffer 346 is located atthe boundary between the solid-state storage clock domain and the localbus clock domain and provides buffering to account for the clock domaindifferences. The synchronization buffer 346, write synchronizationbuffer 308, and read synchronization buffer 328 may be independent ormay act together to buffer data, commands, status messages, etc. In thepreferred embodiment, the synchronization buffer 346 is located wherethere are the fewest number of signals crossing the clock domains. Oneskilled in the art will recognize that synchronization between clockdomains may be arbitrarily moved to other locations within thesolid-state storage device 102 in order to optimize some aspect ofdesign implementation.

The solid-state storage controller 104 includes a storage bus controller348 that interprets and translates commands for data sent to and readfrom the solid-state storage 110 and status messages received from thesolid-state storage 110 based on the type of solid-state storage 110.For example, the storage bus controller 348 may have different timingrequirements for different types of storage, storage with differentperformance characteristics, storage from different manufacturers, etc.The storage bus controller 348 also sends control commands to thestorage control bus 212.

In the preferred embodiment, the solid-state storage controller 104includes a MUX 350 that comprises an array of multiplexers 350 a-n whereeach multiplexer is dedicated to a row in the solid-state storage array110. For example, multiplexer 350 a is associated with solid-statestorage elements 216 a, 218 a, 220 a. MUX 350 routes the data from thewrite data pipeline 106 and commands from the storage bus controller 348to the solid-state storage 110 via the storage I/O bus 210 and routesdata and status messages from the solid-state storage 110 via thestorage I/O bus 210 to the read data pipeline 108 and the control andstatus registers 340 through the storage bus controller 348,synchronization buffer 346, and bank interleave controller 344.

In the preferred embodiment, the solid-state storage controller 104includes a MUX 350 for each row of solid-state storage elements (e.g.SSS 0.1 216 a, SSS 0.2218 a, SSS 0.N 220 a). A MUX 350 combines datafrom the write data pipeline 106 and commands sent to the solid-statestorage 110 via the storage I/O bus 210 and separates data to beprocessed by the read data pipeline 108 from commands. Packets stored inthe write buffer 320 are directed on busses out of the write buffer 320through a write synchronization buffer 308 for each row of solid-statestorage elements (SSS x.0 to SSS x.N 216, 218, 220) to the MUX 350 foreach row of solid-state storage elements (SSS x.0 to SSS x.N 216, 218,220). The commands and read data are received by the MUXes 350 from thestorage I/O bus 210. The MUXes 350 also direct status messages to thestorage bus controller 348.

The storage bus controller 348 includes a mapping module 424. Themapping module 424 maps a logical address of an erase block to one ormore physical addresses of an erase block. For example, a solid-statestorage 110 with an array of twenty storage elements (e.g. SSS 0.0 toSSS M.0 216) per block 214 a may have a logical address for a particularerase block mapped to twenty physical addresses of the erase block, onephysical address per storage element. Because the storage elements areaccessed in parallel, erase blocks at the same position in each storageelement in a row of storage elements 216 a, 218 a, 220 a will share aphysical address. To select one erase block (e.g. in storage element SSS0.0 216 a) instead of all erase blocks in the row (e.g. in storageelements SSS 0.0, 0.1, . . . 0.N 216 a, 218 a, 220 a), one bank (in thiscase bank-0 214 a) is selected.

This logical-to-physical mapping for erase blocks is beneficial becauseif one erase block becomes damaged or inaccessible, the mapping can bechanged to map to another erase block. This mitigates the loss of losingan entire virtual erase block when one element's erase block is faulty.The remapping module 430 changes a mapping of a logical address of anerase block to one or more physical addresses of a virtual erase block(spread over the array of storage elements). For example, virtual eraseblock 1 may be mapped to erase block 1 of storage element SSS 0.0 216 a,to erase block 1 of storage element SSS 1.0 216 b, . . . , and tostorage element M.0 216 m, virtual erase block 2 may be mapped to eraseblock 2 of storage element SSS 0.1 218 a, to erase block 2 of storageelement SSS 1.1 218 b, . . . , and to storage element M.1 218 m, etc.

If erase block 1 of a storage element SSS 0.0 216 a is damaged,experiencing errors due to wear, etc., or cannot be used for somereason, the remapping module 430 could change the logical-to-physicalmapping for the logical address that pointed to erase block 1 of virtualerase block 1. If a spare erase block (call it erase block 221) ofstorage element SSS 0.0 216 a is available and currently not mapped, theremapping module 430 could change the mapping of virtual erase block 1to point to erase block 221 of storage element SSS 0.0 216 a, whilecontinuing to point to erase block 1 of storage element SSS 1.0 216 b,erase block 1 of storage element SSS 2.0 (not shown) . . . , and tostorage element M.0 216 m. The mapping module 424 or remapping module430 could map erase blocks in a prescribed order (virtual erase block 1to erase block 1 of the storage elements, virtual erase block 2 to eraseblock 2 of the storage elements, etc.) or may map erase blocks of thestorage elements 216, 218, 220 in another order based on some othercriteria.

In one embodiment, the erase blocks could be grouped by access time.Grouping by access time, meaning time to execute a command, such asprogramming (writing) data into pages of specific erase blocks, canlevel command completion so that a command executed across the eraseblocks of a virtual erase block is not limited by the slowest eraseblock. In other embodiments, the erase blocks may be grouped by wearlevel, health, etc. One of skill in the art will recognize other factorsto consider when mapping or remapping erase blocks.

In one embodiment, the storage bus controller 348 includes a statuscapture module 426 that receives status messages from the solid-statestorage 110 and sends the status messages to the status MUX 422. Inanother embodiment, when the solid-state storage 110 is flash memory,the storage bus controller 348 includes a NAND bus controller 428. TheNAND bus controller 428 directs commands from the read and write datapipelines 106, 108 to the correct location in the solid-state storage110, coordinates timing of command execution based on characteristics ofthe flash memory, etc. If the solid-state storage 110 is anothersolid-state storage type, the NAND bus controller 428 would be replacedby a bus controller specific to the storage type. One of skill in theart will recognize other functions of a NAND bus controller 428.

Flow Charts

FIG. 5 is a schematic flow chart diagram illustrating one embodiment ofa method 500 for managing data in a solid-state storage device 102 usinga data pipeline in accordance with the present invention. The method 500begins 502 and the input buffer 306 receives 504 one or more datasegments to be written to the solid-state storage 110. The one or moredata segments typically include at least a portion of an object but maybe an entire object. The packetizer 302 may create one or more objectspecific packets in conjunction with an object. The packetizer 302 addsa header to each packet which typically includes the length of thepacket and a sequence number for the packet within the object. Thepacketizer 302 receives 504 the one or more data or metadata segmentsthat were stored in the input buffer 306 and packetizes 506 the one ormore data or metadata segments by creating one or more packets sized forthe solid-state storage 110 where each packet includes one header anddata from the one or more segments.

Typically, a first packet includes an object identifier that identifiesthe object for which the packet was created. A second packet may includea header with information used by the solid-state storage device 102 toassociate the second packet to the object identified in the first packetand offset information locating the second packet within the object, anddata. The solid-state storage device controller 202 manages the bank 214and physical area to which the packets are streamed.

The ECC generator 304 receives a packet from the packetizer 302 andgenerates 508 ECC for the data packets. Typically, there is no fixedrelationship between packets and ECC blocks. An ECC block may compriseone or more packets. A packet may comprise one or more ECC blocks. Apacket may start and end anywhere within an ECC block. A packet maystart anywhere in a first ECC block and end anywhere in a subsequent ECCblock.

The write synchronization buffer 308 buffers 510 the packets asdistributed within the corresponding ECC blocks prior to writing ECCblocks to the solid-state storage 110 and then the solid-state storagecontroller 104 writes 512 the data at an appropriate time consideringclock domain differences, and the method 500 ends 514. The write synchbuffer 308 is located at the boundary between a local clock domain and asolid-state storage 110 clock domain. Note that the method 500 describesreceiving one or more data segments and writing one or more data packetsfor convenience, but typically a stream of data segments is received anda group. Typically a number of ECC blocks comprising a complete virtualpage of solid-state storage 110 are written to the solid-state storage110. Typically the packetizer 302 receives data segments of one size andgenerates packets of another size. This necessarily requires data ormetadata segments or parts of data or metadata segments to be combinedto form data packets to capture all of the data of the segments intopackets.

FIG. 6 is a schematic flow chart diagram illustrating another embodimentof a method 600 for managing data in a solid-state storage device 102using a data pipeline in accordance with the present invention. Themethod 600 begins 602 and the input buffer 306 receives 604 one or moredata or metadata segments to be written to the solid-state storage 110.The packetizer 302 adds a header to each packet which typically includesthe length of the packet within the object. The packetizer 302 receives604 the one or more segments that were stored in the input buffer 306and packetizes 606 the one or more segments by creating one or morepackets sized for the solid-state storage 110 where each packet includesa header and data from the one or more segments.

The ECC generator 304 receives a packet from the packetizer 302 andgenerates 608 one or more ECC blocks for the packets. The writesynchronization buffer 308 buffers 610 the packets as distributed withinthe corresponding ECC blocks prior to writing ECC blocks to thesolid-state storage 110 and then the solid-state storage controller 104writes 612 the data at an appropriate time considering clock domaindifferences. When data is requested from the solid-state storage 110,ECC blocks comprising one or more data packets are read into the readsynchronization buffer 328 and buffered 614. The ECC blocks of thepacket are received over the storage I/O bus 210. Since the storage I/Obus 210 is bi-directional, when data is read, write operations, commandoperations, etc. are halted.

The ECC correction module 322 receives the ECC blocks of the requestedpackets held in the read synchronization buffer 328 and corrects 616errors within each ECC block as necessary. If the ECC correction module322 determines that one or more errors exist in an ECC block and theerrors are correctable using the ECC syndrome, the ECC correction module322 corrects 616 the error in the ECC block. If the ECC correctionmodule 322 determines that a detected error is not correctable using theECC, the ECC correction module 322 sends an interrupt.

The depacketizer 324 receives 618 the requested packet after the ECCcorrection module 322 corrects any errors and depacketizes 618 thepackets by checking and removing the packet header of each packet. Thealignment module 326 receives packets after depacketizing, removesunwanted data, and re-formats 620 the data packets as data or metadatasegments of an object in a form compatible with the device requestingthe segment or object. The output buffer 330 receives requested packetsafter depacketizing and buffers 622 the packets prior to transmission tothe requesting device 155, and the method 600 ends 624.

FIG. 7 is a schematic flow chart diagram illustrating an embodiment of amethod 700 for managing data in a solid-state storage device 102 using abank interleave in accordance with the present invention. The method 700begins 702 and the bank interleave controller 344 directs 604 one ormore commands to two or more queues 410, 412, 414, 416. Typically theagents 402, 404, 406, 408 direct 704 the commands to the queues 410,412, 414, 416 by command type. Each set of queues 410, 412, 414, 416includes a queue for each command type. The bank interleave controller344 coordinates 706 among the banks 214 execution of the commands storedin the queues 410, 412, 414, 416 so that a command of a first typeexecutes on one bank 214 a while a command of a second type executes ona second bank 214 b, and the method 700 ends 708.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive. The scope of the invention is, therefore, indicatedby the appended claims rather than by the foregoing description. Allchanges which come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive. The scope of the invention is, therefore, indicatedby the appended claims rather than by the foregoing description. Allchanges which come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

What is claimed is:
 1. A method comprising: receiving storage commandsat respective command queues, each command queue associated with one oftwo or more banks of a non-volatile solid-state storage device, whereinthe storage commands include storage commands of a first type receivedin an order at a first command queue associated with a first one of thebanks and storage commands of a second, different type, received in anorder at a second command queue associated with a second one of thebanks; issuing commands from the first and second command queues suchthat execution of a first command of the first type overlaps in timewith execution of a second command of the second type, wherein anexecution duration of the first command is at least an order ofmagnitude greater than an execution duration of the second command; andissuing commands from the first command queue in an order different thanthe order in which the commands were received at the first commandqueue.
 2. The method of claim 1, wherein the command queues include oneor more first-in-first-out (FIFO) queues.
 3. The method of claim 1,wherein the first command queue is an erase queue configured to receiveerase commands, and wherein the second command queue is a read queueconfigured to receive read commands.
 4. The method of claim 1, furthercomprising creating subcommands from commands in the command queues; andissuing the subcommands for execution such that a subcommand of a firsttype executes on the first bank concurrent with execution of asubcommand of a second type on the second bank.
 5. The method of claim1, further comprising issuing write commands in the command queues forexecution, wherein the write commands are executable to write datasequentially at an append point that is advanced through the two or morebanks.
 6. The method of claim 1, wherein the issuing of commands fromthe first and second command queues includes selecting the first andsecond commands for execution based on their execution durations.
 7. Amethod, comprising: directing storage commands to respective commandqueues, each command queue associated with one of two or more banks of anon-volatile solid-state storage device, wherein the storage commandsinclude storage commands of a first type directed in an order to a firstcommand queue associated with a first one of the banks and storagecommands of a second, different type, directed in an order to a secondcommand queue associated with a second one of the banks; sequencingexecution of two or more commands in the command queues such thatexecution of a first command of the first type overlaps in time withexecution of a second command of the second type; and executing one ormore write commands in the command queues such that data is writtensequentially at an append point that is advanced through the two or morebanks, wherein commands are issued from the first command queue in anorder different than the order in which the commands are directed to thefirst command queue, wherein an execution duration of the command of thefirst type and an execution duration of the command of the second typediffer by at least an order of magnitude.
 8. The method of claim 7,further comprising: mapping a logical address associated with a readcommand in one of the command queues to a corresponding physical addresswhere data was written within one of the two or more banks.
 9. Themethod of claim 7, wherein execution of the two or more commands issequenced to optimize performance of the banks.
 10. The method of claim7, wherein sequencing execution of the two or more commands includesissuing commands from a command queue in an order different than anorder in which the commands were received at the command queue.
 11. Themethod of claim 7, wherein sequencing execution of the two or morecommands includes selecting the command of the first type and thecommand of the second type for execution based on their executiondurations.
 12. A method, comprising: storing storage commands inrespective command queues, each command queue associated with one of twoor more banks of a non-volatile solid-state storage device; andselecting two or more commands in the command queues for execution suchthat execution of a first command of a first execution duration on afirst one of the banks overlaps in time with execution of a secondcommand of a second, different execution duration on a second one of thebanks, wherein the selecting of the first and second commands forexecution is based on the first and second execution durations, whereinthe first command is of a first type, wherein the second command is of asecond type, and wherein the first and second execution durations differby at least an order of magnitude.
 13. The method of claim 12, whereinthe selecting is performed by an arbiter circuit within the non-volatilesolid-state storage device.
 14. The method of claim 12, wherein theselecting is performed to minimize bus idle time.
 15. The method ofclaim 12, further comprising: issuing commands from a command queue inan order different than an order in which the commands were stored inthe command queue.
 16. The method of claim 12, wherein the selectingincludes selecting write commands in the command queues for execution,wherein the write commands are executable to write data sequentially atan append point that is advanced through the two or more banks.
 17. Amethod, comprising: directing storage commands to respective commandqueues, each command queue associated with one of two or more banks of anon-volatile solid-state storage device; and sequencing execution of twoor more commands in the command queues such that execution of a firstcommand of a first type on a first one of the banks overlaps withexecution of a second command of a second, different type on a secondone of the banks, wherein an execution duration of the first command isat least an order of magnitude greater than an execution duration of thesecond command.
 18. The method of claim 17, wherein the command queuesof a bank include a read queue configured to store read commands, awrite queue configured to store write commands, and an erase queueconfigured to store erase commands.
 19. The method of claim 17, furthercomprising: sequencing execution of one or more commands that were notstored within the command queues.
 20. The method of claim 17, whereinsequencing execution of the two or more commands includes issuingcommands from one of the command queues in an order different than anorder in which the commands were received at the command queue.
 21. Themethod of claim 17, further comprising: sequencing execution of writecommands in the command queues, wherein the write commands areexecutable by the two or more banks to write data sequentially at anappend point that is advanced through the two or more banks.
 22. Themethod of claim 17, wherein sequencing execution of the two or morecommands includes selecting the first command and the second command forexecution based on the execution duration of the first command and theexecution duration of the second command.
 23. An FPGA solid-statestorage controller for controlling execution of storage commands onnon-volatile solid state storage, the storage controller comprisingcircuitry configured to: receive storage commands at respective commandqueues, each command queue associated with one of two or more banks of anon-volatile solid-state storage device, wherein the storage commandsinclude storage commands of a first type received in an order at a firstcommand queue associated with a first one of the banks and storagecommands of a second, different type, received in an order at a secondcommand queue associated with a second one of the banks; issue commandsfrom the first and second command queues such that execution of a firstcommand of the first type overlaps in time with execution of a secondcommand of the second type, wherein an execution duration of the firstcommand is at least an order of magnitude greater than an executionduration of the second command; and issue commands from the firstcommand queue in an order different than the order in which the commandswere received at the first command queue.
 24. An FPGA solid-statestorage controller for controlling execution of storage commands onnon-volatile solid state storage, the storage controller comprisingcircuitry configured to: direct storage commands to respective commandqueues, each command queue associated with one of two or more banks of anon-volatile solid-state storage device, wherein the storage commandsinclude storage commands of a first type directed in an order to a firstcommand queue associated with a first one of the banks and storagecommands of a second, different type, directed in an order to a secondcommand queue associated with a second one of the banks; sequenceexecution of two or more commands in the command queues such thatexecution of a first command of the first type overlaps in time withexecution of a second command of the second type; and execute one ormore write commands in the command queues such that data is writtensequentially at an append point that is advanced through the two or morebanks, wherein commands are issued from the first command queue in anorder different than the order in which the commands are directed to thefirst command queue, wherein an execution duration of the first commandis at least an order of magnitude greater than an execution duration ofthe second command.
 25. A non-volatile solid-state storage devicecomprising: non-volatile solid-state storage arranged in two or morebanks each bank configured to operate independently; and a bankinterleave controller configured to: store storage commands inrespective command queues, each command queue associated with one of thetwo or more banks; and select two or more commands in the command queuesfor execution such that execution of a first command of a firstexecution duration on a first one of the banks overlaps in time withexecution of a second command of a second, different execution duration,on a second one of the banks, wherein the selecting of the first andsecond commands for execution is based on the first and second executiondurations, wherein an execution duration of the first command is atleast an order of magnitude greater than an execution duration of thesecond command.
 26. A non-volatile solid-state storage devicecomprising: non-volatile solid-state storage arranged in two or morebanks each bank configured to operate independently; and a bankinterleave controller configured to: direct storage commands torespective command queues, each command queue associated with one of thetwo or more banks; and sequence execution of two or more commands in thecommand queues such that execution of a first command of a first type ona first one of the banks overlaps with execution of a second command ofa second, different type on a second one of the banks, wherein anexecution duration of the first command is at least an order ofmagnitude greater than an execution duration of the second command.